As a developer, I have spent years writing and learning to parse the meaning of sequences like ==, ===, <=, ~=, and so on. For nearly all of us, the ligatures in this font are completely new. I think it's a creative and interesting idea, but it means re-training my brain to recognize them, which would take time.
And even if I could get my preferred editors to work with it, I would see the traditional symbols when reading code on the web, or pairing with another developer who does not use the font. It seems like a barrier to understanding, something that by nature developers strive to eliminate.
I'm torn. This idea could be something that changes how we all express code symbolically, or it will just become a fad that a tiny percentage of developers will insist on using, to the frustration of everyone else.
> ..developers will insist on using, to the frustration of everyone else.
I'm thinking It won't change the underlying text so I imagine it will only apply to the individual developer choosing to apply these ligatures on their display, as such should have little effect on other devs. Unless you mean to say people might start to use this in documentation and code examples, in which case this is indeed an interesting thing to consider.
The difference between e.g. -> and --> is a length of a small solid line. To me that's equates to a huge drop in readability, countering the easy to brain-parse argument.
Have you tried the font? = and == has 3× difference in width, it’s hard to mistake one for another. I’m using Fira Code for a year now, never had mixed them up
At least for me, monospaced fonts are very helpful for looking at column specific features. == and === are row specific, so seeing the delimiters between them makes them easier to parse on a row level for me.
The brain is very good at turning complicated features in to abstract concepts. In fact that is mostly what some parts do. So, not clear if this actually improves things or not.
For example, the == and === look quite a bit similar in the font. You have to compare relative sizes, whereas with the normal fonts you can count the spaces.
You probably mean = and ==. They have 3× difference in width, which, in practice (I’m using Fira Code for a year now), is more than enough to tell the difference.
Regarding the difference between == and ===, latter has three lines (and so does !==), so in fact in Fira Code === and !== the looks implies the meaning, whether in other cases you have to bend your mind to accept that negation of “three equals” is a “two equals and a bang”
I'm not sure why this has to be done in the font. Vim has support for conceal characters, which can "conceal" syntactic constructs into other characters, i.e., any Unicode code point. This works out pretty well in LaTeX documents for example, because you can see the mathematical symbols. [1]
One gripe I have though is that columns become misaligned when you have concealed characters or ligatures. In the source, \alpha is 6 columns and \beta is 5. Displayed, α and β are both 1 column. This messes up things like visual block insert mode, because the location of that column in the source and what's being displayed might differ. Should you line up the displayed version and make it look nice for you and those with the same plugin, or don't you?
I have been using Fira Code font with Atom for some time and I am absolutely in love with the aesthetics. All credit and praise goes to http://tonsky.me/
Just give it a try. There’s 3× difference in width, so _in practice_ you won’t mistake them, ever. I’m using that font for a year now, not a single case of misreading
After so many years, there's still no better coding font than MS Consolas. I use it everywhere (where by "everywhere" I mean Linux and OSX, since I don't use any MS products other than this font).
When it comes to my eyesight, why settle for anything but the best? Consolas is free as in beer to use. I just checked it into my dotfiles which I clone to all my machines.
Maybe that's what it is now, but there was a window of time when Microsoft offered it as a free download off MSDN to anyone who wants it. That's when I got my copy.
I'm trying out Atom, and ligatures in Erlang don't always render. For example, -> in the head of a function clause doesn't render as a ligature, while inside the function body it does.
I tried using ligatured when Pragmata added them, but the issues made me return to the normal version.
If you use your editor for multiple languages and documentation as well, you may find things like lines in comment blocks made of '%', '#', or '-' to break from the ligatures. Also if your doc markup(-down) uses underlines of '-' or '=' for headings, they are affected.
On Windows, I found some editors where the ligatures were enabled, some where they weren't, and not many where you had any option to toggle either way.
Vim isn't there problem, it's your terminal. There is an open feature request with iterm2, but terminal.app is probably a lost cause. I know nothing about the state of Unicode font rendering in Linux.
Konsole is the only terminal emulator I could get it working with, which is annoying because I much prefer rxvt. Konsole does weird stuff with my terminal colors in tmux, so I ended up not being able to use this nice font when I tried it previously.
Probably not possible with ligatures/glyph variants but really cool would be grouping of numbers: In groups of three the first digit would be moved to the right and the last one to the left to simulate a narrow space as thousands separator.
It's a shame the C/C++ standards committee(s) didn't just copy Verilog's base-n notation when they added the "0b" prefix. It's nice to be able to write large constants with optional underscores every four or eight digits, e.g. 32'hffff_0867_5309_beef, or 12'b1101_1110_1010.
Neat, I didn't know they'd done something similar with single quotes. (No law said they had to allow constants to start with an underscore, of course...)
I think the relevant issue is whether the editor can render the OpenType ligatures (well, contextual alternates) contained in the font.
You _could_ convert to .ttf, changing the curves to TrueType-style quadratics, but they'd still have to have the OpenType substitution tables for the "ligatures" to work, and I don't think that would really improve compatibility much, if at all.
See I knew it was a silly question :)
A few minutes ago I converted the otf files to ttf using font forge. That appeared to work, but it seems the ligatures are gone. On top of that the ttf version of the font did not show up as a monospaced font in my code editor. I might have done something wrong though as I only dabble a bit with font forge.
Then I just did what you suggested, install the otf instead (d'oh) Now the fonts do show up as monospaced font. But my editor does not display the ligatures. But at least it is usable.
No, it is an editor called "the hammer" [1]. As it is I am one of the developers of that editor. It is rather specialized and targets the programming language DataFlex. The editing component is based on the codemax component. While I have access to all the code, I'm not sure on how-to add ligatures support.
Vim and emacs are terminal applications, thus it's down to the terminal emulator to support the font. Some terminal emulators do (eg Konsole). However many do not.
Frankly, I'm amazed at the number of programmers who have made the complaint about vim and emacs support since writing terminal applications (ie stuff that prints to STDOUT) is basically programming 101. It should be pretty obvious to any programmer where the support is required.
That's not emacs then, it's a Cocoa / Win32 / whatever port of emacs. Unless your talking about "graphical" in the same sense that ncurses is. But either way, emacs default behaviour is a terminal application.
I just installed GNU Emacs on my PC and it seems you're right. I swear that never used to be the case; or maybe I've only ever used emacs on headless servers so it defaulted to the terminal renderer? Weird - but sorry for arguing with you on that point.
:-) I guess even ancient 80s (?) software keeps with the times to some degree. Notwithstanding all the idiosyncratic (in our environment) defaults for ergonomics and terminology..
The ligatures don't work because lots of editors don't bother to use text rendering that supports ligatures. It's an interesting perspective to blame that on the font.
And even if I could get my preferred editors to work with it, I would see the traditional symbols when reading code on the web, or pairing with another developer who does not use the font. It seems like a barrier to understanding, something that by nature developers strive to eliminate.
I'm torn. This idea could be something that changes how we all express code symbolically, or it will just become a fad that a tiny percentage of developers will insist on using, to the frustration of everyone else.