This repository was archived by the owner on Dec 15, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 15, 2022. It is now read-only.
OpenType features on decimal separators are disabled #364
Description
This is how a number renders:
<span class="constant numeric decimal js">
42<span class="meta delimiter decimal period js">.</span>2
</span>Because the decimal is in a separate element, OpenType contextual replacement feature does not work across the entire number. For instance, a typeface might contain two different period glyphs – one for text, and the other for decimal separator.
This is how the DOM needs to look for the feature to work:
<span class="constant numeric decimal js">
42.2
</span>I understand that somebody might be relying on this extra element for, perhaps, syntax highlighting the decimal separator. There seems to be a clear conflict of features, and it is up to you to make the call.
Activity
MaximSokolov commentedon Apr 17, 2016
Do you mean ligatures? Could you post a screenshot and sign what font on it? I am curious how does it look like.
Originally it was part of fixing numbers like
.1(#319) Nobody asked for it before.Alhadis commentedon Aug 23, 2016
@denis-sokolov I sorely doubt OpenType ligatures for decimal points are used in raw source code. I can't for the life of me imagine why anybody would want the decimal point of a float displayed differently to regular accessors.
MaximSokolov commentedon Aug 23, 2016
e.g. FiraCode and Hasklig. Though I am not sure how this affects decimal point
Alhadis commentedon Aug 23, 2016
Sorry, I should've clarified what I meant. Fixed.
(I am familiar with Haskell and its operators, so I should've known better).
Alhadis commentedon Aug 27, 2016
Paging @denis-sokolov one last time, because I'm curious to find out what font he's using that actually uses this sort of ligature.
denis-sokolov commentedon Aug 27, 2016
Admittedly, it's not a popular typeface. Purisa-code, it's on my GitHub
profile.
I believe a decimal number is a single token: we don't highlight different
digits in a non-decimal number: 6744. What's different about the decimal
part? In my typeface the decimal point is tiny and you read the entire
number at once.
But the dot as a property accessor (or method invocation) is majorly
important in the code. In code chains it is important to see the steps
separated:
foo.bars.filter().forEach().On Aug 27, 2016 09:34, "John Gardner" notifications@github.com wrote:
Alhadis commentedon Aug 27, 2016
To be honest, I agree with the part about numbers being perceived as a solitary unit. Similarly, a leading sign indicator shouldn't be highlighted differently, either:
Oddly enough, the sign indicator of an exponential component doesn't receive different highlighting, which makes the overall composition pretty inconsistent. There're potentially three different colours being used to depict a single number.
@50Wliu, thoughts?
winstliu commentedon Aug 27, 2016
It has been previously attempted to include the optional leading
+/-as part of the number. That didn't work because- 5in3 - 5would get tokenized as a number and not as an operator and a number.Remember, all this (excluding ligatures) is customizable in your themes.
denis-sokolov commentedon Aug 27, 2016
But isn't the goal of a grammar to understand the language and distinguish
unary and binary operators?
On Aug 27, 2016 19:12, "Wliu" notifications@github.com wrote:
winstliu commentedon Aug 28, 2016
Yes, however there are limitations to the regex-based model. Take, for example, this JavaScript snippet:
How does the parser know that the
-is actually an operator?denis-sokolov commentedon Sep 3, 2016
I am not one to comment to the viability of the current model or why it's been chosen. But I don't think we actually need 100% accuracy, do we? Also, this counter-example does not apply to the decimal point that the issue is about. :)
Alhadis commentedon Sep 3, 2016
Considering this grammar is being used to highlight the most popular programming language on Earth, on the biggest open source community in the world (all of GitHub), I'd say accuracy is pretty damn important.
denis-sokolov commentedon Sep 3, 2016
That's an abstract statement. The context where I said we don't need 100% accuracy is where currently we arguably have an even worse accuracy (detecting unary vs binary
-). Perfect is the enemy of good.winstliu commentedon Sep 3, 2016
Back to the decimal point...there may very well be people who would prefer that it was stylized differently than the surrounding numbers, as you said in the original post. In fact, the syntax theme I'm using (Fizzy) colors it differently.
Alhadis commentedon Sep 3, 2016
I think this is a non-issue, quite frankly.
denis-sokolov commentedon Sep 3, 2016
@50Wliu, as I said, it's your call. In my personal opinion it is as strange to style the decimal point differently as styling individual digits. The entire number is a number, and I would have preferred for it to be rendered as a single number. I don't have any further argument.
winstliu commentedon Sep 3, 2016
/cc @atom/languages @esdoppio
hediyi commentedon Sep 4, 2016
Ligatures set aside, I say we comply with the parsers when we can.
Resulted tokens parsing
-2.2e-2; 4.2;:winstliu commentedon Dec 8, 2016
I'm thinking of flip-flopping on this issue based on my work with language-java and some of the comments above. Give me a few more days to think about this.
Alhadis commentedon Dec 8, 2016
*googles flip-flopping to figure out what that meant*
Strewth.