51–60 of 84 posts
As a developer, I have spent years writing and learning to parse the meaning of sequences like ==, ===, 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…
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.
Earlier quoted context omitted.
Do you not like Inconsolata? https://www.google.com/fonts/specimen/Inconsolata
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.
Earlier quoted context omitted.
They don't. The == variant is has double the width.
I am aware, I still find them too similar for my likings
"Your eye spends non-zero amount of energy to scan, parse and join multiple characters into a single logical one." citation needed
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. 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”
On what planet does it make sense to release a programming font which explicitly refuses to support both vim and emacs?
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…
As a developer, I have spent years writing and learning to parse the meaning of sequences like ==, ===, 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…
= vs == vs === seems like a sure way to have bugs.
My thoughts exactly. Probably depends on the person but I am certainly the type who would have trouble detecting the difference.
Earlier quoted context omitted.
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.
Have you tried urxvt, by any chance?
Tried all kinds of variations of
> fnt="xft:Fira code:pixelsize=10:size=15"; urxvt -fn "$fnt" -fb "$fnt" -fi "$fnt" -fbi "$fnt" -letsp -1
My build is:
rxvt-unicode (urxvt) v9.21 - released: 2014-12-31
options: perl,xft,styles,combining,blink,iso14755,unicode3,encodings=eu+vn+jp+jp-ext+kr+zh+zh-ext,fade,transparent,tint,pixbuf,XIM,frills,selectionscrolling,wheel,slipwheel,smart-resize,cursorBlink,pointerBlank,scrollbars=plain+rxvt+NeXT+xterm
Earlier quoted context omitted.
I'm finding it works fine in OS X's Terminal.app and (by extension) emacs and vim (El Capitan 10.11).
Good news. What about standalone (not terminal-based) Emacs on OSX?