
Read and understand code faster with programming ligatures in Fira Code font - icos
https://visualstudioextensions.vlasovstudio.com/2017/05/01/improve-code-readability-with-programming-ligatures-in-fira-code-font/
======
return0
I would be very hesitant to use this. It's not "more intuitive" as the author
would like to think. In fact , our visual system has been trained to instantly
recognize a!=b in code, and I read code a lot more often than Math formulas.
Plus code is not math (e.g. 1+(a>0)), confusing = with == will lead to lots of
errors etc.

If I get used to this font on my machine, i will have a real problem when
parsing code in another terminal/editor. Unless all the programmers in the
world decide to switch to it simultaneously, this introduces a mental
translation that's counterproductive.

~~~
coldtea
> _In fact , our visual system has been trained to instantly recognize a!=b in
> code_

Citation needed.

> _confusing = with == will lead to lots of errors etc_

This is more about NOT confusing == with = -- and several similar characters
than the opposite.

Sounds like you have thought of all kinds of arguments to not actually try it
and see whether it's any good in practice -- which is how anything should be
judged (unless it involves some huge risk). In other words, a priori
rationalization.

> _If I get used to this font on my machine, i will have a real problem when
> parsing code in another terminal /editor._

The above argument advices to forever stick to a lowest common denominator
coding toolset, lest one has to ever try to work in other environment.

How about maximizing the performance one gets from their own, and most
frequently used, environment, instead of "what-ifing" for foreign systems they
might have to use 1/10 of the time or less?

Plus, having a tool at our disposal and getting used to it doesn't mean we
can't also do without if needed. Especially if it's a small improvement, like
the one proposed by the ligatures here, and not some totally different notion
that we can't ever go back to how it was without it...

~~~
carterehsmith
The thing is, in general, if you are promoting some change, you need to show
that it brings benefits.

So the onus is on promoter - to show benefits.

The onus is _not_ on everyone in the world to show whether the idea works or
not.

~~~
coldtea
Promoters (or, to be more precise, creator) might really not care to prove
anything. And I wouldn't trust their arguments either.

If the change is harmless enough to try, one can just see for themselves.

And for things that work for some people but not for others, some general
proof doesn't make sense anyway.

Nobody came and proved me how vim can work better for my editing than Emacs. I
tried both myself and found out. Several for tons of other things that I
adopted or not.

------
gumby
This isn't really what I thought it would be. I don't want != changed to ≠
because ≠ isn't a C++ operator.

What I thought would be true ligatures ("tying together") of "&&" which could
still be recognized as a pair of ampersands, but by being conjoined cleanly
appear to be symbol in their own right, which is what "&&" is.

However part of the value of ligatures is symbol tightness, which is defeated
by the need for a monospaced font.

Still, I'm glad people are experimenting!

~~~
coldtea
> _I don 't want != changed to ≠ because ≠ isn't a C++ operator._

A colored != is not a C++ operator either. It's about getting our minds to
differentiate symbols faster, not about whether they exist as is in some
language's syntax.

~~~
gumby
Indeed, I program with syntax coloring disabled for this reason.

~~~
coldtea
Then maybe program directly in C++ AST. != will be converted to that too.

------
tylerhou
Does this strike anyone else as a gimmick? I'm not sure if parsing symbols is
really the limiting factor when I try to understand code.

~~~
failrate
It is no more a gimmick than the standard mode of rendering. However, it does
have an adaptation cost. A comparable example: I went to the trouble of
creating a custom key binding for my old laptop that was a standard US layout,
except the numeral row was symbols by default (i.e. Press shift to get
numbers), because I only used the numpad for numerals. It worked, but
relearning was too painful. If I'd learned it that way from the beginning, it
would just be normal.

------
andy_ppp
Very interesting but I hate this for programming, feels wrong when I'm so used
to 1 char == 1 fixed with char. I'm sure I could adapt but for some reason it
makes my sense of programming taste not happy. What do others think?

~~~
anotheryou
It takes some time to get used to and it's annoying to place the cursor
correctly to backspace from != to =.

But it looks sexy and confuses the co-workers XD. Joke aside: I actually like
making my PC mine and like the look. I don't think it makes me a faster or
better programmer in any way...

------
aratno
While these are cool for complete code snippets, they are distracting during
coding. For example, the colon contextual alignment flickers as the context is
typed, and that distraction alone outweighs any convenience of a merged
symbol.

------
al452
I've been using this in IntelliJ IDEA for about a month.

The experience reminds me of adopting an anti-aliased font for coding, for the
first time (many years ago). First half an hour of unfamiliarity and
skepticism, then it just seems very natural, and reading code feels smoother
and easier and more productive.

I absolutely cannot stand code in non-monospaced fonts, so I don't think there
are any alignment problems. (The look of Fira Mono / Fira Code isn't really to
my taste though, so I'm hoping for the same things to start popping up in
other fonts too!)

~~~
Latty
There are lots of others - my personal favourite is Monoid.
[http://larsenwork.com/monoid/](http://larsenwork.com/monoid/)

------
jsjohnst
Anybody else despise the look of many of these ligatures? One of the worst is
the design of the ampersand.

~~~
return0
I don't even think they add much to readability. If i could choose, the only
ligatures i 'd like would be >= and !=

------
combatentropy
I love typography and ligatures, but this introduces a layer of abstraction in
your source code. I know it sounds depressingly uninternational, but I don't
even like to use Unicode characters in my text files. I prefer a one-to-one
mapping of keyboard button to on-screen character. Although I suppose even
capital letters break that rule, so maybe one day I'll give it a whirl.

------
Something1234
I'm not sure that I want my equality signs to be ligature'd together. I feel
like using this might mess up alignment in a monospace font.

~~~
Chris_Newton
Usually the ligatures in these fonts are designed to fill the same width as
the original combination of separate characters in monospace use. That does
preserve the alignment of code to either side of the ligature, but
unfortunately at the expense of either making some of the symbols much wider
than normal or adding a lot of extra whitespace to pad them out. For
programming, the ligatured version seems quite risky if it means the only
visual difference between single and double equals or underscore characters is
a bit of width and/or horizontal padding.

What I _would_ like to try is a language where = actually meant equality
rather than assignment and a few other common operators like !=, ===, !==, <=
and >= all appeared using the standard mathematical symbols at the same width
as =, < and >. That way, some related cases would naturally line up and most
lines with comparisons would become shorter and less cluttered, which seems
like a modest incremental improvement in language syntax. Alas, you’d also
need software and keyboard input to support that in a way that made those
alternative symbols effortless and entirely predicable to use. This feels like
a job for a standardised programmer’s keyboard and AltGr, except that you’d
need a standardised programmer’s keyboard for each of the different languages
that already uses AltGr for other purposes, and at some point it all becomes
more trouble than it’s worth.

------
captn3m0
I'm assuming this doesn't take care of context?

For eg:

String s = "A != B";

would render the ligature inside the string?

~~~
altern8tif
I don't think Fira Code recognizes context. It just parses the characters and
renders multi-character glyphs into a single one.

So the inequality inside the string will be afforded the same treatment as an
inequality anywhere else in the code.

------
jobigoud
Lua's not equals `~=` gets ligatured to ≃ instead of ≠. Expected but
unfortunate.

~~~
abeyer
Most of Lua was nicely obvious and intuitive, but ~= was always one of the
weird sharp edges. I could _maybe_ see the argument for using it if ~ was
already a negation operator of some sort (like C's bitwise complement) but Lua
doesn't even have that. Instead you get something needlessly non-intuitive and
subject to misinterpretation by anyone who isn't a Lua native, as ~= as an
ASCIIfication of ≃ is pretty common.

------
gvd
So far this font has worked really well for me for Haskell, C++, Python. I
find it very readable

------
yread
I like the idea but the xml tags </ /> look horrible

------
cutler
Ligatures aside, I tried this font in IntelliJ and found the letter spacing to
be far too wide.

------
bshimmin
I quite like the "contextual vertical align". Everything else I find either
visually unappealing (eg. the ampersand, as already mentioned) or outright
confusing (the equality glyphs in particular).

------
wildpeaks
If you want to use Fira Code in Visual Studio Code, use this in settings.json:

    
    
        "editor.fontFamily": "Fira Code"
        "editor.fontLigatures": true

------
st3fan
It looks pretty but totally does not work for my brain.

------
proyb2
It doesn't took us long to decode == or >= operator naturally.

------
mcphage
It would be cool if it turned .\ into a greek lambda as well.

------
jimu
wow. someone worked really hard to solve a problem that doesn't exit

