I'm assuming this doesn't take care of context? For eg: String s = "A != B"; would render the ligature inside the string?
So the inequality inside the string will be afforded the same treatment as an inequality anywhere else in the code.
31–40 of 43 posts
I'm assuming this doesn't take care of context? For eg: String s = "A != B"; would render the ligature inside the string?
So the inequality inside the string will be afforded the same treatment as an inequality anywhere else in the code.
Anybody else despise the look of many of these ligatures? One of the worst is the design of the ampersand.
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 anoth…
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 anoth…
> 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…
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.
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…
> 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.
"editor.fontFamily": "Fira Code"
"editor.fontLigatures": trueI 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 anoth…
I had every one of those concerns too. In spades. And then I actually tried using it for real, and none of the concerns turned out to cause any problem in practice. (Why would I try using something I was confident would make me less productive? Because I felt was in a rut, and was trying out disruptive changes to my workflow. For example the same day, I switched all my calculator tools to RPN. That's not gone badly e…