41–50 of 87 posts
True, which is why Iosevka has language-specific ligatures that a sufficiently smart editor (I think the "JS types", like Atom/VSCode, have CSS for this) can use to ligate (?) intelligently.
Earlier quoted context omitted.
This isn't just some blogger though. Matthew Butterick wrote http://practicaltypography.com/ .
A self-published eBook that acknowledges a lack of funding on the main page? Maybe it is required reading in typography circles, but to someone reading the submission who merely uses a font, this doesn't seem much of a credential.
He's doing something really interesting with the funding model of practicaltypography, that I believe should be praised.
I think ligatures can be a great feature, but they should not be decided by the font, but by the editor. So you can can destinguish between 'input >> var' and 'vector >' and render the literature in one case but not the other. This and more creative text decorations can be really helpful to read code. Other examples are rendering css colors inline, rendering of tables and formulas in emacs, ...
Earlier quoted context omitted.
A self-published eBook that acknowledges a lack of funding on the main page? Maybe it is required reading in typography circles, but to someone reading the submission who merely uses a font, this doesn't seem much of a credential.
"A self-published eBook that acknowledges a lack of funding on the main page?" is kind of a low blow. He's doing something really interesting with the funding model of practicaltypography, that I believe should be praised.
I'm merely explaining that to the reader not a student of typography, there's not really any indication that this should be taken with more authority than 'some blog author' per comments above.
I think ligatures can be a great feature, but they should not be decided by the font, but by the editor. So you can can destinguish between 'input >> var' and 'vector >' and render the literature in one case but not the other. This and more creative text decorations can be really helpful to read code. Other examples are rendering css colors inline, rendering of tables and formulas in emacs, ...
That's a hard one to get right; for a long time, C++ compilers would tokenize 'vector >' incorrectly and throw a syntax error -- the final two angle brackets had to be separated by a space for the code to compile.
Honestly, this sounds like the kind of argument you could present about how syntax highlighting is a terrible idea. It might be wrong! I don't use ligatures, but I really don't see a problem with other people using them. It's fine, it's a style preference thing, that, like fonts and colour schemes, is as much fashion and personal preference as it is anything. But it's fine.
If your syntax highlighting is wrong, it's buggy. Proper syntax highlighting is 100% correct.
Earlier quoted context omitted.
What's bad about them? (I find the arguments in the link interesting, but not all that convincing)
I work with someone who uses them and I find it impossible to read his screen. Unless you work completely alone, it's a terrible idea.
If you work with people over the internet, it doesn't matter because they can disable ligatures and still read your code. And obviously it's not a problem if people know them and are looking on your screen.
But yeah, if you're doing pair programming and first dev is used to them and the second dev is not, that's a problem. The question is, is the solution that the second dev learns them or that the first dev stops using them - both will obviously dislike changing the way they like to code...
Earlier quoted context omitted.
This isn't just some blogger though. Matthew Butterick wrote http://practicaltypography.com/ .
A self-published eBook that acknowledges a lack of funding on the main page? Maybe it is required reading in typography circles, but to someone reading the submission who merely uses a font, this doesn't seem much of a credential.