Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
curio77 opened this issue Sep 2, 2016 · 11 comments
Closed

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

curio77 opened this issue Sep 2, 2016 · 11 comments

Comments

@curio77
Copy link

curio77 commented Sep 2, 2016

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.)?

@curio77 curio77 changed the title Side effects of the new ".)" ligature Side effects of the new ".)" ligature (also ".]") Sep 2, 2016
@tonsky
Copy link
Owner

tonsky commented Sep 2, 2016

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

@curio77
Copy link
Author

curio77 commented Sep 2, 2016

Thanks for the quick reply and agreement! :-)

@alexisvl
Copy link

alexisvl commented Sep 5, 2016

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
Copy link

stromnov commented Sep 7, 2016

screenshot 2016-09-07 19 34 41

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

@shawnlindstrom
Copy link

shawnlindstrom commented Sep 8, 2016

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

@benfleis
Copy link

benfleis commented Sep 9, 2016

+1 on rollback, also found it very strange.

@tonsky tonsky closed this as completed in 3468af1 Sep 17, 2016
@krux02
Copy link

krux02 commented Sep 25, 2016

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

@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
Copy link
Author

curio77 commented Sep 25, 2016

@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
Copy link

krux02 commented Sep 25, 2016

@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
Copy link
Owner

tonsky commented Sep 25, 2016

@krux02 seems reasonable #279

@curio77
Copy link
Author

curio77 commented Sep 25, 2016

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants