OpenType features on decimal separators are disabled

[denis-sokolov]

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.

[MaximSokolov]

Do you mean ligatures? Could you post a screenshot and sign what font on it? I am curious how does it look like.

I understand that somebody might be relying on this extra element for, perhaps, syntax highlighting the decimal separator.

Originally it was part of fixing numbers like .1 (#319) Nobody asked for it before.

[Alhadis]

@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]

I sorely doubt OpenType ligatures are used in raw source code

e.g. FiraCode and Hasklig. Though I am not sure how this affects decimal point

[Alhadis]

Sorry, I should've clarified what I meant. Fixed.

(I am familiar with Haskell and its operators, so I should've known better).

[Alhadis]

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]

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:

Paging @denis-sokolov https://github.com/denis-sokolov one last time,
because I'm curious to find out what font he's using that actually uses
this sort of ligature.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#364 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAG8OehCaRlgMeQaR6CUxQR2lMCROfeLks5qj-hqgaJpZM4IJFuJ
.

[Alhadis]

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]

It has been previously attempted to include the optional leading +/- as part of the number. That didn't work because - 5 in 3 - 5 would 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]

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:

It has been previously attempted to include the optional leading +/- as
part of the number. That didn't work because - 5 in 3 - 5 would get
tokenized as a number and not as an operator and a number.

Remember, all this is customizable in your themes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#364 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAG8OWcCCDoq9qvXRsMjXS23PZcTjYuNks5qkG_4gaJpZM4IJFuJ
.

[winstliu]

Yes, however there are limitations to the regex-based model. Take, for example, this JavaScript snippet:

let x = 3
-5;

How does the parser know that the - is actually an operator?

[denis-sokolov]

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]

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]

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]

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.