Ligatures, IMO, make for a bad coding editor experience. No, I do not want >> parsed as a right shift when it's actually used as two adjacent template delimiters. And no, I'm not okay with the inconsistency that results from the usage of different operators from one programming language to another. Want to change a != to a == operator? Enjoy futzing with placing the cursor properly. It's a cute idea, but I found it more annoying to use in practice.
To each their own. I have never found them confusing or annoying in a half a dozen languages. If it doesn’t improve readability for your brain then definitely turn them off. In a language like Go or JS there aren’t very many operators so it’s not as bad as C might be. Still a great font without ligatures
> No, I do not want >> parsed as a right shift when it's actually used as two adjacent template delimiters.
I don't like ligatures either, but I think that this depends on the editor. For example, if typing Rust in IntelliJ, if you type `Box<Box<String>>`, it will show two regular ">" characters. But if you type `x >= 3`, it will replace it with a single glyph.
But, to your point, it would seem it doesn't enable ligatures based on the parser, since there is a difference between ligatures active and disabled, and it applies on both lines.
Not who you asked, but I use dark mode in VS Code and Sublime usually. But those are the defaults. I do use default fonts. I generally don't change defaults.
However.
If ligatures were turned on by default, I would turn them off.
Ligatures seem like the light theme in your analogy. I do NOT want my code looking one way in the editor, and another when reading PRs on the web. Consistency is king, and this just feels like bells and whistles some designer came up with.
Same reason one uses spaces over tabs, except in Makefiles because someone decided tabs are mandatory. With spaces copying the code from one place to another doesn't change the indentation too much.
I'm sure I would get used to it after a while, but right now I'm having trouble even reading the examples. I don't need my editor to be too special.
> I do NOT want my code looking one way in the editor, and another when reading PRs on the web.
Some PR tools let you select your font. I think more should.
For one example on the web today, you can use github.dev (shortcut '.' on the github.com page for the PR) to open GitHub PRs in the web version of VS Code, which will Settings Sync, including font choice, with your regular VS Code profile. (Though, of course, that uses the GitHub Issues and Pull Requests extension to provide PR tools, and you can also just install that same extension locally into VS Code and never visit the web in the first place and just use VS Code for PR reviews if you like.)
Sounds cool, but I'm comfortable in vim. I'm curious though, what black magic does it use to sync the web to my local dotfiles? Or does VS Code have cloud accounts now?
It does support a cloud-based sync tied to either your GitHub account and/or Microsoft account.
If you prefer a more traditional git-based dotfiles sync, github.dev and GitHub Code Spaces will also look for a public or private repo under your account called dotfiles.
I don't think vscode.dev has a way to provide a dotfiles repo, though, and I think it only supports the cloud sync. (vscode.dev is the other web hosted VS Code like github.dev but for other generic things like its Theme Playground and a subset of github.dev functionality for Azure Repos missing things like PR review support because there is no equivalent extension to GitHub Issues and Pull Requests for Azure Repos.)
So what you're suggesting is vendor lock-in to solve my goal of consistency independent of context? What about Gitlab, Slack, mailing-lists? And the killer feature for losing that is ligature support?
I do have dotfiles repo but no VSCode stuff there, and no Microsoft account, might explain why I never got past the "setting up your web editor" screen when I tried the '.' shortcut.
I'm not suggesting vendor lock-in is necessary which is exactly why I mentioned there were multiple ways to do that. I think it is great to have options.
It was also just one example I knew of where code review tools were getting more respectful of user preferences. I stated pretty plainly that I wish a lot more tools were doing that beyond the examples that I knew. I'd love to see more font options in code review tools.
I don't know about Gitlab and the last I used Slack I had wished it had font options because I hated whatever fonts they chose that they thought aligned best with their brand. Mailing lists are actually an easy answer: use a mail client that happily lets you switch an email's fonts. (I used to do that when reading code in mailing lists in Thunderbird to switch from the default proportional fonts of email to a monotype font and back. I assume Thunderbird still has features like that, but it has been forever since I've personally been on a mailing list involving code reviewing.)
Of course I realize I can change the font? We can do pretty much anything we want if we put the energy in it. I already do in my WM, terminal, vim, mutt and everything else on desktop. If I really wanted to I could replace the font in code and pre block as well with just a few lines of css in a user script, but ligatures is not the feature that will make me do it. Maybe to remove them, that would be an idea if they become mainstream.
You're missing my point, I don't want to have to set a special font for everything I use. Simplicity and minimalism is my way. Not VSCode + Microsoft account + github.dev, I have no use for either. I could do it in my current tools, until a client uses something else, and I would have to set it up again. Or maybe I'm in a VM, not logged into github.com and reading some repository.
The ancient Python maxim is "Code is read a lot more than it is written" and I've always found that to be true. Looking nice is a benefit to readability. Readability is a key part of maintainability (you have to find what you are about to edit first). I find that I'm more likely to catch simple mistakes with ligatures than without, which is also a boon to editing/maintainability. (For example of that, in JS/TS development Fira Code's === ligature isn't just wider, but has an entire third extra line in the vertical stack, making it in my opinion far easier to spot.)
Exactly. Personally I like to have it very obvious exactly what characters are in my file. But I also do agree that it looks very nice and can appreciate why people prefer it.
You can generally configure that in your viewer/editor on if to use ligatures or not, separately from the font itself... but if it isn't in the typeface, you don't even get the option if you do want it.
They're definitely polarizing, in the sense that some people intensely dislike them and never use them, others love them and always use them.
It reminds me of the debates about font antialiasing back in the 1990s. A vocal minority of programmers then insisted that font antialiasing wasn't suitable for coding, as a pixel-oriented monospace font (e.g. Monaco at 9 points) provided better text density and better readability[1].
Then, like now, I could see the validity of the arguments of both sides. Readability is a highly subjective thing (and also varies over time, even for the same person). And the screens and antialiasing algorithms of the day weren't as sophisticated as what we now enjoy.
Personally I waffled on it for a while, but now I always code with ligatures enabled in my main work (which is predominantly using TypeScript and Rust, so the default ligatures of these fonts make sense).
I suspect that the majority opinion will shift to using ligatures for coding (if it hasn't already) once that is the default experience of most editors with the default fonts, and it becomes something you have to turn off, rather than turn on.
[1]: This is an example of Monaco, although what they show as 12 point is how I remember 9-point looking... not sure if my memory is faulty or what, though, it was a long time ago. https://www.fontriver.com/font/monaco/
Idk, my editor/terminal disables the ligatures when my cursor hovers over them, so that's not a problem.
It's absolutely a personal preference thing, and I personally prefer it. At least for the languages that I typically work with. I could see it being annoying with certain languages.
My biggest problem is that despite them supposedly being supported by windows 10 I can never get it to work correctly even on totally fresh installs. I’m 0 for 5 at this point. If someone has the magic that actually fixes this, please share. (And yes I enabled utf-8).
Also kinda meta but I see three different font related links on the homepage right now? Just coincidence?
It's often a separate configuration option in various editors... I know you have to enable it explicitly in VS Code, for example. It's not on in applications by default.
I never found it hard to edit code with ligatures when I used them. I don't use them anymore, but I don't understand some people's need to shout about how bad they are. Don't use them if you don't like them, use them if you like them, simple as that.
