Hm. I was hoping maybe neovim (being, in some sense - "new" vim) might have fixed this -- apparently not (yet) -- looks like it's still modelled too closely on vim (not that that's a surprise, or all bad -- I suppose it was too much to hope for that this kind of design errors would be (easier to) fix(ed) this early:
Proper font handling is actually one of the few things that I find troubling with these "old" nix tools.
The combination of nice font handling and otherwise being lightweight (and working fine without any borders, which makes sense when paired with xmonad for a window manager) was one of the reasons I moved to Sakura:
(Not on my Linux box atm - so unable to test if ligatures actually work -- but either way it would appear vim does a little too much -- so even if the terminal handles ligatures, vim will not. Time to upgrade to ed! ;-)
I wonder if kakoune[1] supports ligatures in a capabable terminal? I'm guessing not, but have yet to try.
Also, I just discovered that AbiWord actually have a setting to get vi(m) keybindings -- not that I'd suggest moving from vim to abiword for editing code...:
Based on the issue[2] for Emacs support, it looks like the general "easy" approach is monkey-patching from two-symbols to unicode ligatures and back on the fly. Such an approach would probably work with vim too -- it'd probably be just as well to handle that bit via a pre/post processor -- and just type in the combined symbols directly in vim (eg: iab >= ≥ to insert the symbol for "greather-then" rather than >= -- and then just deal with editing that as a single symbol. You'd need to run the source through a transformation to change all occurrences back -- for most langauges -- so I'm not sure if it's really a good idea. But seems simpler if you just want ligatures, and there's a unicode glyph that matches the ligatures you want.
Ahem, well -- from the Haskling site: "Some Haskellers have resorted to Unicode symbols (⇒, ← etc.), which are valid in the ghc. However they are one-character-wide and therefore eye-strainingly small. Furthermore, when displayed as substitutes to the underlying multi-character representation, as vim2hs does, the characters go out of alignment."
So then again, maybe not. I suppose we just have to wait for the next display server tech to reinvent display PostScript along with a friendly API ...
https://github.com/neovim/neovim/issues/1408
Proper font handling is actually one of the few things that I find troubling with these "old" nix tools.
The combination of nice font handling and otherwise being lightweight (and working fine without any borders, which makes sense when paired with xmonad for a window manager) was one of the reasons I moved to Sakura:
http://www.pleyades.net/david/projects/sakura
(Not on my Linux box atm - so unable to test if ligatures actually work -- but either way it would appear vim does a little too much -- so even if the terminal handles ligatures, vim will not. Time to upgrade to ed! ;-)
I wonder if kakoune[1] supports ligatures in a capabable terminal? I'm guessing not, but have yet to try.
Also, I just discovered that AbiWord actually have a setting to get vi(m) keybindings -- not that I'd suggest moving from vim to abiword for editing code...:
http://www.abisource.com/wiki/Keyboard_bindings
Based on the issue[2] for Emacs support, it looks like the general "easy" approach is monkey-patching from two-symbols to unicode ligatures and back on the fly. Such an approach would probably work with vim too -- it'd probably be just as well to handle that bit via a pre/post processor -- and just type in the combined symbols directly in vim (eg: iab >= ≥ to insert the symbol for "greather-then" rather than >= -- and then just deal with editing that as a single symbol. You'd need to run the source through a transformation to change all occurrences back -- for most langauges -- so I'm not sure if it's really a good idea. But seems simpler if you just want ligatures, and there's a unicode glyph that matches the ligatures you want.
Ahem, well -- from the Haskling site: "Some Haskellers have resorted to Unicode symbols (⇒, ← etc.), which are valid in the ghc. However they are one-character-wide and therefore eye-strainingly small. Furthermore, when displayed as substitutes to the underlying multi-character representation, as vim2hs does, the characters go out of alignment."
So then again, maybe not. I suppose we just have to wait for the next display server tech to reinvent display PostScript along with a friendly API ...
[1] https://news.ycombinator.com/item?id=9764028
[2] See gist linked from issue: https://github.com/i-tu/Hasklig/issues/10