[SCdF]

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.

[toast0]

I think this comment gets at the root of the issue. This is syntax highlighting, but it's done by the font rendering engine and it has no context.

Syntax highlighting without context is not really a good experience. The highlighter needs to know what language you're using, and a pretty good idea of how to parse it.

And the comment on ligatures below points out, this is actually true of ligatures for human languages as well, but I doubt the font engines are properly tuned for that either. I'd make an exception for the 'obvious' ligatures like gg gy etc where the descenders were overlapping without a ligature. That shouldn't be an issue in a monospaced context though.

[eridius]

If your syntax highlighting is wrong, it's buggy. Proper syntax highlighting is 100% correct.

[falcolas]

Depending on your language, proper syntax highlighting (without parsing the entire program) is nearly impossible.

For example, in C, what highlight category do you give to '*c'? A declaration, a dereference, or a multiplication call?

In Lisp, is the first element of a list a macro or a function (or a value)? If there's a reader macro, it gets even harder.

[oneeyedpigeon]

Syntax highlighting doesn't necessarily have to work at the lowest granularity, though; for some uses, merely distinguishing between comments and non-comments is acceptable, and that's still 'syntax highlighting'. Of course, as you point out, true 100% syntax highlighting needs to fully parse the entire program; why not do that, though? I guess it would be too computationally expensive for certain sizes of program, but it could still update in near-realtime, no?

[eridius]

Syntax highlighting doesn't need to precisely classify every single character according to how the language would parse it. So with your `*c` example, I wouldn't actually expect a syntax highlighter to highlight that at all.

But every classification the highlighter does do must be accurate, or it's a buggy highlighter.

And FWIW, it's certainly possible to write a syntax highlighter that does parse the whole program. You'd normally find this in an IDE rather than a programmer's text editor. For example, writing Swift in Xcode, everything gets precisely highlighted, to the point where references to real types are highlighted whereas references to unknown types (e.g. typos) aren't. It's not practical to do this outside of IDEs, which is why most syntax highlighting only tries to highlight that which it can unambiguously determine.

[larma]

Correct syntax highlighting is subjective, because color selection is a matter of taste.

[gaius]

Nope, you or I may think reserved words should be red or blue, but either the list of words that get highlighted is correct, or it isn't.