[hieronymusN]

The use of ligatures in Hasklig is very intriguing. Would really like to see more work in this vein. Could see benefits to Clojure (arrows) and even => in JavaScript.

EDIT: Looks like FiraCode has ligatures too https://github.com/tonsky/FiraCode

[mdcox]

This could be really cool, but I can also see it getting distracting and increasing oversight. The >= and <= signs look nice in Fira Code and Hasklig, but I worry I'd accidentally see them as > and < when debugging. Either way, I can't really try it because neither of those are usable in vim with iTerm2 and I'm not changing my whole toolchain just to try a font.

[niccaluim]

Oh my yes, this is very nice indeed. Probably the first real advancement I've seen in programming fonts in decades.

[e12e]

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:

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

[a-nikolaev]

I think, you may get oddly looking code with such ligature fonts if you declare your own operators that contain ligatured pieces as parts.

For exmaple the operator >>== will probably have the first three characters joined in the ligature {>==}=

Operators ==== and (four asterisks) may look very strange too.