"l·l" Ligature in "Source Code Pro" incorrectly invoked when render whitespace is enabled

[SL-Lee]

• VSCode Version: 1.49.0
• OS Version: Windows 10

Steps to Reproduce:

1. Set editor.renderWhitespace to all.
2. Set editor.fontFamily to Source Code Pro (ensure you have the font installed on your system).
3. Set editor.fontLigatures to false (this issue is not reproducible if this setting is not set to false).
4. Open a new editor and type l l (a lowercase letter "l", followed by a space, followed by another lowercase letter "l").

Screenshot of this bug:

When editor.renderWhitespace is set to all, the whitespace character (U+0020) is rendered as the middle dot unicode character, · (U+00B7). Coincidentally, "Source Code Pro" has a ligature that comprise of the characters l·l (see the screenshot above), so this might be the reason why the ligature is invoked.

Does this issue occur when all extensions are disabled?: Yes

[alexdima]

This does not reproduce when running with --disable-features=LayoutNG

[alexdima]

Workaround: configure "editor.fontLigatures": "'liga' off, 'calt' off"
configure "editor.fontLigatures": "'ccmp' off"

[alexdima]

OK. I have actually found out quite a number of things while investigating this:

• https://wakamaifondue.com/ can be used to upload a font and get a list of all the font features settings available in that font
• Source Code Pro has 37 available font feature settings: 'case', 'ccmp', 'cv01', 'cv02', 'cv04', 'cv06', 'cv07', 'cv08', 'cv09', 'cv10', 'cv11', 'cv12', 'cv14', 'cv15', 'cv16', 'cv17', 'dnom', 'frac', 'locl', 'numr', 'onum', 'ordn', 'salt', 'sinf', 'ss01', 'ss02', 'ss03', 'ss04', 'ss05', 'ss06', 'ss07', 'subs', 'sups', 'zero', 'mark', 'mkmk', 'size'
• By doing a binary search on them, it is the font feature setting named 'ccmp' that is causing l·l to be rendered with a different glyph.
• Here is what I could find about ccmp
• It looks like Source Code Pro registers a ligature for the character sequence l·l. The · is the character we use to render whitespace.
• This ligature is no longer disabled via 'liga' off, 'calt' off as it used to be the case in the past.

TL;DR: This has changed since VS Code 1.49 because we have upgraded to Electron 9, which ships layoutNG. I am not convinced this is a bug, it might just be something unique about Source Code Pro. The workaround is to use "editor.fontLigatures": "'ccmp' off"

[timo-suoranta-varjo]

TL;DR: This has changed since VS Code 1.49 because we have upgraded to Electron 9, which ships layoutNG. I am not convinced this is a bug, it might just be something unique about Source Code Pro. The workaround is to use "editor.fontLigatures": "'ccmp' off"

I run into this issue as well. If this is a not a bug, what is it? I don't mind having fine control over font features (that sounds great actually). However, there really should be a simple setting that effectively disables all use of font ligatures. Something like "editor.fontLigatures": "all off", but it would be even better if false actually meant "all off".

[rezonant]

The fact that the editor uses an actual text character (·) to implement whitespace indicators seems like an implementation detail. I'd say since the user didn't intentionally insert ·, its a bug if ligatures fire on that character sequence. Maybe not easy to fix (I don't know), but I do think this is a bug. The user entered l l (elle space elle) not l·l (elle dot elle) and the ligature is not intended to trigger for l l.

Furthermore, the caret positioning for the rest of the line becomes incorrect:
See this result with the problematic ligature turned on:

See this result once "editor.fontLigatures": "'ccmp' off" is applied:

Furthermore, the caret position jumps around when faced with navigating the line after the ligature occurs, and selection also assumes it is rendered as if the ccmp feature is off:

[jonnyhoff]

I had the same issue.
@alexdima 's fix solved the issue.

"editor.fontLigatures": "'ccmp' off"

[fitojb]

Copying here what I commented in adobe-fonts/source-code-pro#260:

IMHO that should be solved by VSCode by switching to the proper Unicode character, U+2027, instead of reusing U+00B7, which is an orthographic character in the Catalan language and other related Romance languages like Occitan. VSCode shouldn't ask font developers to make their fonts substandard in a human language to accomodate for their software's quirks.

[gjsjohnmurray]

@fitojb makes a reasonable point, but switching will make the visible whitespace harder to see.

[gjsjohnmurray]

Another screenshot with some more options plus a first line showing how the current choice (MIDDLE DOT) looks when visible whitespace is enabled. This time I have also used "Zoom In". Compare lines 1 and 3 to see how the dimming of visible whitespace affects the visibility of the chosen character.

Theme: Dark+

Theme: Light+

My test file:
visibleWhitespace.txt

[timo-suoranta-varjo]

@fitojb makes a reasonable point, but switching will make the visible whitespace harder to see.

That depends on what font user is using.
This could be mitigated by whitespace color preference/setting.
Possibly there could be a preference/setting to customize which glyphs are used for whitespaces.
And/or how about glyph replacement map: allow individual glyphs to be remapped to another glyph.

[nic-hartley]

I'm a bit confused. The text being rendered is already different from the text being interacted with (e.g. there's a dot there, where there isn't in the text). So why can't we just render &NoBreak;<dot>&NoBreak; (or similar with ZWSP, etc. -- any of the zero-width space characters) to break up the ligature? I don't actually know Unicode well enough to say which would be the best, NoBreak was just the first one I thought of.

That way we preserve the aesthetic, which admittedly I do like the best out of the options, while still not causing problems for fonts which define the Catalan ligature, AFAIK without needing to tweak rendering code significantly.

ETA: my hesitation isn't sarcasm, I'm just not familiar enough with VS Code's internals to know whether this is really an option.

[imaami]

Just a reminder that this bug is still a problem (deb package version 1.56.2-1620838498).

[farfromunique]

This is still a problem, and having to set ligatures to "'ccmp' off" is not a great fix. I assumed that setting ligatures to false would turn ligatures off, not ... ignore settings related to them? I guess? (I'm not actually sure what it does).
More intuitive or expressive options for editor.fontLigatures would be a good thing, as would not having ligatures show up due to rendered whitespace.

[icelewsi]

@jonnyhoff me too

[av-2024]

Just updated to latest VSCode. This issue remains unfixed.

[Drulex]

Also suffering from this.

[Long0x0]

I'm a bit confused. The text being rendered is already different from the text being interacted with (e.g. there's a dot there, where there isn't in the text). So why can't we just render &NoBreak;<dot>&NoBreak; (or similar with ZWSP, etc. -- any of the zero-width space characters) to break up the ligature? I don't actually know Unicode well enough to say which would be the best, NoBreak was just the first one I thought of.

That way we preserve the aesthetic, which admittedly I do like the best out of the options, while still not causing problems for fonts which define the Catalan ligature, AFAIK without needing to tweak rendering code significantly.

ETA: my hesitation isn't sarcasm, I'm just not familiar enough with VS Code's internals to know whether this is really an option.

U+200C ZERO WIDTH NON-JOINER (‌) should be a better option, which break the ligatures and keep the original width. from wikipedia:

The zero-width non-joiner (ZWNJ) (‌) is a non-printing character used in the computerization of writing systems that make use of ligatures. When placed between two characters that would otherwise be connected into a ligature, a ZWNJ causes them to be printed in their final and initial forms, respectively. This is also an effect of a space character, but a ZWNJ is used when it is desirable to keep the words closer together or to connect a word with its morpheme.