I (personally) don't exactly want == to look too similar to a single =, after all!
Me, either!
Amusingly (irritatingly?), /== has separation between the = characters. :/
I... have no idea why ~= turns into ~-on-top-of-= and =~ into =-on-top-of-~ . Some of these glyphs just seem ill-advised. :(
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.
They didn't use underscores because _100_000 is a valid identifier in C/C++.
Arbitrary bases aren't there.
1 000 000
100 000 0
And assume we only support 4-10 digit numbers, it would require e.g. 6 rules or so.
But substitutions are done left-to-right, that might be a problem
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.
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.
For instance, the HTML comment bookends. In Fira, they are long arrows. In plain ASCII they are enclosing brackets connecting to comment.
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.
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.
citation needed
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.
The rest of the ligatures look pretty cool!
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”
EDIT: In developer mode I can see the -> is being rendered as two single character <span>s when in the head of the function. The solution is probably to fix it in the grammar definition: https://github.com/jonathanmarvens/atom-language-erlang/blob...
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?
For instance, some languages use != and others use ~=. If both of those look the same, you're going to have one hell of a time learning a language.
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.