Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ligatures in programming fonts

tinyletter.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Ligatures in programming fonts

#71

Post by oneeyedpigeon »

falcolas wrote: post #57
eridius wrote: post #39

Earlier quoted context omitted.

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

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.

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?

Re: Ligatures in programming fonts

#72

Post by oneeyedpigeon »

wodenokoto wrote: post #64

Do ligatures really act like one character? I've never encountered not being able to select only the f ro the i in a 'fi'-ligature, but I don't really use ligatures outside of word processing.

Some of the ligatures in Fira Code are so radically different from the characters they're substituting, that single-character selection would be incredibly confusing. How would it behave for the characters on the final line of the sample, for example?

Re: Ligatures in programming fonts

#73

Post by eridius »

falcolas wrote: post #57
eridius wrote: post #39

Earlier quoted context omitted.

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

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.

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.

Re: Ligatures in programming fonts

#74

Post by gvx »

robert-boehnke wrote: post #17
panic wrote: post #7

The first problem isn't really a problem, since ligatures are provided by fonts, not character encodings. From the Unicode FAQ on ligatures and digraphs ( http://unicode.org/faq/ligature_digraph.html ): "The existing ligatures exist basically for compatibility and round-tripping with non-Unicode character sets. Their use is discouraged. No more will be encoded in any circumstances. "Ligaturing is a behavior encoded i…

Isn't the choice of font inherently an editor feature like syntax highlighting?

I don't think they're talking about the choice of font, but instead the choice of replacing certain character sequences (e.g. ->) with glyphs (e.g. →).

Re: Ligatures in programming fonts

#75

Post by OJFord »

cmyr wrote: post #70
OJFord wrote: post #45

Earlier quoted context omitted.

I'm not meaning to deal any blows at all, low or otherwise. 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.

From a brief bit of clicking around, the author has: designed several typefaces[1], written a long text on typography[cited previously], and has done enough programming to have developed the publishing framework he uses in his books[2], and to have written another book on a programming topic[3]. While I don't agree with much of this blog post, I certainly think the author has put in enough work to have their work tak…

I'll state just once more, in order to be absolutely clear that I harbour no ill intent: I have no reason to doubt, having been told, that the author can be regarded an authority on the matter. I'm simply saying that, approaching it fresh, it's not obviously the case, and other commenters' disregard should not be treated as that for a household name.

Re: Ligatures in programming fonts

#76

Post by Johnny_Brahms »

crazygringo wrote: post #54
anorakoverflow wrote: post #31

The author's point about "dumb" ligatures doesn't really hold up: While the "fi" ligature will always mean "f followed by i" its use is not always correct. For example, in German compound nouns, you do not set a ligature between the two nouns. For instance, "Kaufläche" (Kau: chewing, + Fläche: area) should be written with ligature, while in "Kaufleute" (Kauf: purchase, + Leute: people, = merchants) the ligature shoul…

Wow, that's fascinating -- do you have a reference for that? I'd love to learn more, especially as to why -- it seems like that would just result in ugly typography. Or is it solely about the bar of the initial "f" connecting to the next letter?

Well, typography is often about readability. Removing the word boundary in compound nouns isn't really helpful since it removes a boundary that conveys meaning.

There were some examples of nouns where you should avoid ligatures in the TeX docs iirc. Shelfful and selffullfilling are the only ones I remember.

In German (every single fff on any page that bothers to set their own fancy-pants font) and swedish text you see it all the time, often coming from self-proclaimed typesetting/font nerds.

Re: Ligatures in programming fonts

#77

Post by [deleted] »

crazygringo wrote: post #54
anorakoverflow wrote: post #31

The author's point about "dumb" ligatures doesn't really hold up: While the "fi" ligature will always mean "f followed by i" its use is not always correct. For example, in German compound nouns, you do not set a ligature between the two nouns. For instance, "Kaufläche" (Kau: chewing, + Fläche: area) should be written with ligature, while in "Kaufleute" (Kauf: purchase, + Leute: people, = merchants) the ligature shoul…

Wow, that's fascinating -- do you have a reference for that? I'd love to learn more, especially as to why -- it seems like that would just result in ugly typography. Or is it solely about the bar of the initial "f" connecting to the next letter?

[deleted]

Re: Ligatures in programming fonts

#78

Post by MrQuincle »

kps wrote: post #60
MrQuincle wrote: post #28

Earlier quoted context omitted.

Unicode is a disadvantage for someone who wants to contribute to your code. That person now has to figure out how to write down Unicode arrows, taking her/him out of her/his flow.

Sure, and the Dane has to figure out how to write down ø, taking them out of their flow — until they learn to apply the correct tool for the job.

I'm not sure if you're sarcastic or not. However, I'm Dutch, and we have similar tokens.

Nobody minds if you write Danish code, but if you like contributors, it is asking a lot of them to change their editor or tools to collaborate with you. I hope you didn't mean your collaborators have to adjust to you like that.

Re: Ligatures in programming fonts

#79

Post by jstewartmobile »

Somewhat off-topic, but the explosion Unicode glyphs can lead to problems more serious than aesthetics:

Punycode exploit: https://www.xudongz.com/blog/2017/idn-phishing/

Greek question mark: https://stackoverflow.com/questions/26965331/javascript-pran...

Shameless plug: https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C

Post reply on HN