Side effects of the new ".)" ligature (also ".]")

[curio77]

I don't really know why this was added, but the ligature for ".)" (yielding "·)") also comes up in text containing sentences inside parentheses, where it's clearly undesirable and irritating. I'd like to see this reconsidered. If one happens to have a sentence in square brackets, the same applies ("[Yada yada·]"). I reckon such uses are much more frequent than actual usages in the context of that obscure language.

If there's a strong incentive to have such obscure (!) ligatures for specific languages, wouldn't it be possible to create separate sub-variants of the font for them so that users can select the sub-variant most suited for their purposes or even use different ones in different contexts (console vs. IDE, etc.)?

[tonsky]

Right, haven’t thought about that. Will have to roll back that one

[curio77]

Thanks for the quick reply and agreement! :-)

[alexisvl]

Variants would be really nice! There are a few ligatures that are useful when programming, but a bit annoying when they show up in e.g. written text. Enterprising users with very configurable GUI editors could even get fancy and switch to a different variant for different syntax contexts (comments, string literals, etc)...

[stromnov]

Side effect of .] ligatures in Python output (NumPy).

[shawnlindstrom]

FWIW, also applies to "(." and "[." yielding "(·" and "[·". In my odd case, text for parenthetical reference to file extensions, e.g. (.xlsx).

[benfleis]

+1 on rollback, also found it very strange.

[krux02]

I was so happy to see some Nim support in this font, and now I am sad again :cry:

@curio77 I feel a bit insulted when you call Nim an obscure langue. I spent a lot of time recently programming in that language, and I really like it. It is by fact a very unknown programming language, but that doesn't make it obscure. It might even have obscure features, but that's even more true for current popular programming languages.

[curio77]

@krux02 Sorry if this came across as insulting, it wasn't meant so — I considered “obscure” an adequate adjective to concisely summarize the fact that it is presumably a language with a very small user base compared to the totality of programming languages and also the total user base of FiraCode. This is a view you seem to concur with.

While it may be sub-optimal for your usage of FiraCode with Nim, I hope the above comments have made you see the much broader detriment the now-reverted changes brought about in other, presumably much more frequently applicable contexts.

Ideally, as I even suggested in my original report, @tonsky might come up with a way of implementing a process of enabling users to generate customized variants of the font with a sub-set of possible ligatures, enabling mixing and matching for those with specialized requirements. But until this is possible, I think that the only sane approach to adding ligatures is to limit them to ones with close to no side effects for the majority of users (there will always be singular cases where a ligature replacement may be undesirable, but this is the nature of the syntactic rather than semantic application of them).

[krux02]

@curio77 You wouldn't believe it, but the user base for "obscure" programming langues also correlates to useres of "obscure" fonts, "obscure" editors and even "obscure" keyboards and keyboard layouts. I think obscure people should stick together and support each other because of their diversity and their urge to use something better than the default. I wrote about this font in the Nim community and the reaction was quite positive, also because it had some special Nim treatment. But I surely see the problem, especially the one with .). But my personal opinion about .} stays the same. {. and .} are the truly important ligature for Nim, on the other hand in written text curly braces {} are very rare. Additionally this font is primarily for programming not for editing text, so the weight should be a bit more on the side of the programming languages, especially the obscure ones. And ending numbers on a dot is something I simply don't do anymore at all. I used to write that notation, too in the beginning now where I also know programming languages that allow to do dot calls on numbers (Scala, Nim) 7.toString, I think it's just plain ugly do end a number on a dot or even to allow it. It was also never allowed to use that notation in school on paper. I know I would not be able to convince any Python programming or C++ programmer to change their habits, but maybe I could open their mind, that their perspective might be the obscure one even though they have the unarguably more poplar programming language.

But truly this mix and match feature could make everybody happy who is willing to compile his own font.

[tonsky]

@krux02 seems reasonable https://github.com/tonsky/FiraCode/issues/279

[curio77]

@krux02 Briefly, I didn't complain about “{.”/“.}”. But as for the other things, you should always remain aware of the fact that Unicode ligatures are very much just a bit of syntactic sugar, the lack of which, at worst, makes things look less nice (but in no way hinders your development work). On the other hand, out-of-context ligatures may make things harder to read and cause confusion, which IMHO is much worse and, by extension of the principle of least surprise, should be avoided. As for “.)” and “.]” in particular, which tend to occur in fragments of text, these do cause confusion in practice because source code tends to contain comments (and also possibly larger amounts of text, think Javadoc, Doxygen).