191–200 of 207 posts
Earlier quoted context omitted.
Over the last 10-15 years or so, I’ve tried so many of these new fonts but always just end up back to DejaVu Sans Mono Bold. Now that my eyes are getting older, it works even better. On a Mac, Menlo looks nearly identical.
I'm the same, except I stick with Consolas, rather than DejaVu. But it almost feels like trying out new fonts is busywork...
I always applaud efforts at new typefaces, but unfortunately I feel this is a badly designed typeface that is worse for legibility, not better. Addressing their three main points in turn: > 1. Increased height for a better reading experience A high x-height is good for coding fonts, but this x-height is now too high. To my eye, this is now at the point where lowercase letters are getting harder to distinguish from up…
Over the last 10-15 years or so, I’ve tried so many of these new fonts but always just end up back to DejaVu Sans Mono Bold. Now that my eyes are getting older, it works even better. On a Mac, Menlo looks nearly identical.
Earlier quoted context omitted.
IANAL - I am pretty certain you can do most of those things with all fonts regardless of license. Copyrights on fonts is almost non-existent. The only thing copyrightable is the actual "code" used in the font. (maybe delivering their files on a website is an issue?) This is based on research I did years ago when dealing with a copyright legal case where I worked. The summation is that you can't copyright the alphabet…
You can't copyright 0s and 1s, so it's okay to do whatever you want with any binary?
I'm quite surprised no serious "programming font" to this days didn't come with something improving camelCase readability: making ligature for each lowerUPPER combination with slightly wider center gap and narrower first character (so that sum was still in monospace grid) would FMPoW tremendously boost readability and would be remedy for camelCase haters. I've searched for it lately and the only what resembled this w…
Theoretically yes. But in practice most possibly no. OpenType tables just feature fixed length strings matching. It can't match to more powerful regular expressions. You would need an infinite number of OT rules. [0] If you'd have a well defined set, maybe it could work, but it would still be overwhelming fast.
Earlier quoted context omitted.
What's stopping editors to provide shortcuts akin to ligatures? Eg. typing "=>" would make use of the "follows" sign.
And now you can only type code in the set of blessed editors and correctly displaying fonts. "Make code pretty" should be a matter of presentation, not actual source code. To use your example, typing "=>" could display the "follows" sign, but the string representation should not depend on exotic characters like "ř", "⸙", or "" (is that a box symbol, or "symbol not found in current font"? Oh wait, the HTML input field…
Most development IDEs are configurable and extendable in such a way. Or well, at least the one I am using is (Emacs). Just like opinionated languages have not had those choices stop them from becoming widespread (eg Python re indentation), so shouldn't the character set used either.
You could also redefine your keyboard layout (eg. a happy hacking keyboard has no marks on the keyboard) or come up with a programming input method (IM) to use — not everyone would have to do it, someone would make it and others would use it. But making wider use of the characters available has to start somewhere, and it can't start with input systems (before there's a widespread need for them).
Earlier quoted context omitted.
So does JetBrains IDE's and VS Code. I don't know of any program that forces you to use ligatures just because the typeface supports it.
Visual Studio (the full blown IDE)
"editor.fontLigatures": false
Earlier quoted context omitted.
And now you can only type code in the set of blessed editors and correctly displaying fonts. "Make code pretty" should be a matter of presentation, not actual source code. To use your example, typing "=>" could display the "follows" sign, but the string representation should not depend on exotic characters like "ř", "⸙", or "" (is that a box symbol, or "symbol not found in current font"? Oh wait, the HTML input field…
In general, I agree with the principle: presentation and source code are not tied together. But we've been constrained to ASCII for programming for far too long. Sure, there are benefits, but is there a way forward? How can we know if we don't explore it. Most development IDEs are configurable and extendable in such a way. Or well, at least the one I am using is (Emacs). Just like opinionated languages have not had t…
Earlier quoted context omitted.
Over the last 10-15 years or so, I’ve tried so many of these new fonts but always just end up back to DejaVu Sans Mono Bold. Now that my eyes are getting older, it works even better. On a Mac, Menlo looks nearly identical.
Haha same. I've tried so many as well... Inconsolata, Fira Code, etc. Always end up back with Menlo.
Earlier quoted context omitted.
Same. Any font that claims to be for programming but includes ligatures gets a "no thanks" from me accompanied by a bit of sadness because they often mar otherwise nicely designed typefaces.
As I know, VSCode, Iterm2, Jetbrains IDEs have ligatures option that we can turn on/off easily.
Earlier quoted context omitted.
Many fonts having "real italics" would use a different shape, whereas those with only "slanted fonts" would not (like Verdana). It's only a rough rule, but you can assume that most serif fonts will use "real italics".
The words you're looking for are italic and oblique :-) One is a different design, the other simply the same letterforms slanted.
And while I agree "oblique" is a more technical term, "slanted" is frequently used to mean the same thing, and is probably more understandable. Perhaps I am wrong and it isn't :)