Firacode: Hexadecimal ex, URLs and escaped chars not working on Sublime Text
turkeyphant
All 7 comments
Thin slash should be enabled:
"font_options": ["ss06"]
Hexadecimal ex doesn’t seem to work, that’s Sublime Text limitation.
What about URLs that doesn’t work?
tonsky
on 1 Jul 2020
Thanks. I wasn't aware about Sublime Text not doing the hex ex. I guess that's why you don't get the red symbols either?
URLs I saw here but I guess that's not a feature?
turkeyphant
on 2 Jul 2020
The ligatures are red on the README samples to highlight the ligatures added by the font, it's not part of the font.
wopian
on 2 Jul 2020
Fair enough. I thought I'd seen them in other people's examples too but I guess not. I assume URLs are also displaying as intended in my example? If so, I will close.
turkeyphant
on 2 Jul 2020
www is not supported either. Here: https://www.sublimetext.com/docs/3/ligatures.html
Sublime Text currently only supports ligatures comprised from the following characters: !, ", #, $, %, &, ', (, ), *, +, ,, -, ., /, :, ;, <, =, >, ?, @, [, \, ], ^, _, `, {, |, }, ~.
Hope this will change one day. Sublime is my primary editor too
tonsky
on 2 Jul 2020
I wish www were one of those you can turn off.
turkeyphant
on 2 Jul 2020
The reason we only support symbols is performance.
In order for ligatures to work, you need to "shape" text by passing a string with the unicode characters to the OS text layout engine, which returns glyphs to represent the string. The text shaping is generally fairly slow, thus we must cache the results. There are not very many combinations of symbols present in most text files, thus we don't have too many unique runs of symbols that have to be shaped and cached.
As soon as you start shaping runs of letters and numbers, the number of cached glyph runs can get out of hand quickly – it becomes slow and uses a bunch of memory. Just imagine opening a log file with 50,000 lines, each starting with a unique timestamp. You now have 50k glyph runs, even if you break on whitespace.
Instead, we shape individual graphemes for things that aren't runs of symbols. This way we get a fair tradeoff of: ligatures for the most common case (symbols), but also good performance and memory usage.
wbond
on 3 Jul 2020
Related issues
magnus-madsen
·
3Comments
ghivert
·
4Comments
pamu
·
3Comments
RustemB
·
4Comments
tomByrer
·
4Comments
Most helpful comment
The reason we only support symbols is performance.
In order for ligatures to work, you need to "shape" text by passing a string with the unicode characters to the OS text layout engine, which returns glyphs to represent the string. The text shaping is generally fairly slow, thus we must cache the results. There are not very many combinations of symbols present in most text files, thus we don't have too many unique runs of symbols that have to be shaped and cached.
As soon as you start shaping runs of letters and numbers, the number of cached glyph runs can get out of hand quickly – it becomes slow and uses a bunch of memory. Just imagine opening a log file with 50,000 lines, each starting with a unique timestamp. You now have 50k glyph runs, even if you break on whitespace.
Instead, we shape individual graphemes for things that aren't runs of symbols. This way we get a fair tradeoff of: ligatures for the most common case (symbols), but also good performance and memory usage.