-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Comments
Right, haven’t thought about that. Will have to roll back that one |
Thanks for the quick reply and agreement! :-) |
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)... |
FWIW, also applies to "(." and "[." yielding "(·" and "[·". In my odd case, text for parenthetical reference to file extensions, e.g. (.xlsx). |
+1 on rollback, also found it very strange. |
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. |
@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). |
@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 truly this mix and match feature could make everybody happy who is willing to compile his own font. |
@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). |
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.)?
The text was updated successfully, but these errors were encountered: