Some icons use RTL unicode characters and can mess up surrounding text

[jdrouhard]

Some icons switch the active direction of text to RTL and affect the surrounding text. Specific examples are the latex icon (extension .tex) and the SVG icon. I know there are others as well, but #46 is a result of this issue specifically for the latex icon.

I don't have a PR yet (I could produce one if desired), but I was able to completely resolve these issues in my config by overriding the offending icons to add LTR Unicode direction isolates around the icon text. The Unicode consortium introduced these isolates to specifically help with issues like this. Text inside the isolate markers cannot affect the direction of the surrounding text, and as long as the terminal emulator properly supports the Unicode bidi algorithm, using the isolates fixes many of the rendering issues.

I've verified that if the icon text is surrounded with LTR isolate markers (LRI .. icon .. PDI), then the icons will no longer mess up the rendering of surrounding text if the terminal emulator properly applies the bidi algorithm (modern terminal emulators do). Isolates specifically do not affect the direction of the surrounding text so this won't affect rendering if the icon appears in RTL text.

Maybe the icons that use codepoints that are designated as RTL (Tex, SVG, etc) should have LTR isolate markers around the unicode codepoint. This would involve something like:

["tex"] = {
    icon = "<U+2066>ﭨ<U+2069>", -- actual utf-8 encoded codepoints instead, this is for demonstration
    color = "#3D6117",
    name = "Tex"
  };
...

I have this override in my config and it corrected rendering issues with telescope.nvim and fzf-lua when they rendered the tex icon in their popup windows.

Another possibility is changing the get_icon() function to wrap the icon text in the isolate markers before returning, possibly with a memoization.

[kyazdani42]

hi !
I wouldn't encode each character icon by default, but maybe encoding only the needed icons should suffice, maybe making some rtl_wrap function that you would pass like icon = rtl_wrap('ﭨ'). My terminal handles this by default so i cannot really spend time debugging this, but you could make a PR when you have time :)

[l1n3n01z]

hi ! I wouldn't encode each character icon by default, but maybe encoding only the needed icons should suffice, maybe making some rtl_wrap function that you would pass like icon = rtl_wrap('ﭨ'). My terminal handles this by default so i cannot really spend time debugging this, but you could make a PR when you have time :)

Your terminal "works" because it does not handle RTL at all. More featureful terminals do. Mintty and Kitty at least. So really this is a bug and should be fixed.

The smallest possible fix would be to fix it in the default icons. Check which icons there are RTL and wrap them with the correct characters manually. This would mean that the defaults are not broken for users of terminals that support RTL.

[alex-courtis]

Thank you @l1n3n01z

The pragmatic solution is indeed to use a sane terminal.

[jdrouhard]

This shouldn't have been closed yet.

[alex-courtis]

This shouldn't have been closed yet.

What is outstanding? This is a problem with the terminal, not nvim-web-devicons.

[l1n3n01z]

This shouldn't have been closed yet.

What is outstanding? This is a problem with the terminal, not nvim-web-devicons.

There is still an outstanding bug in Unicode handling in this project.

Mintty is the only terminal for WSL that behaves correctly for a variety of TUI tools. Kitty is one of the most popular terminals on Mac.

These terminals are sane in the way they handle RTL characters. That is, for people who use RTL alphabets in their day to day work in a terminal environment. They also behave correctly in this regard according to the semantics of Unicode.

Terminals that don't handle RTL correctly are deficient for this particular use case.

When a project decides to use Unicode characters that have particular semantics for display purposes, they have a responsibility to do so in a sane way.

I have described an easy solution. In the default configuration, shield the character with characters that change the semantics so that it can be used for display purposes.

Another solution would be to only use Unicode characters in the default configuration that you actually know how to use correctly.

The solution that you seem to have chosen, to ignore the problem, means that users will first have to understand what is wrong, which takes a long time.

Then they have to do one of the following:

1. Find a terminal that is objectively worse for their day to day work (i.e. switch to a terminal that suck for WSL, switch to a terminal that doesn't handle terminal graphics or that doesn't handle colors or cannot render their native language in the way it should when writing emails or for note taking)
2. Change the default configuration, with the caveat that this needs some extra coding to handle color scheme changes.
3. Stop using a project that makes their nvim file tree slightly prettier but messes up the text rendering in a lot of cases.
4. Fork the project, locally or otherwise, which means maintenance.

The default config should not break text rendering in any modern terminal. You have had several bug reports on this issue. Maybe fix it instead of being facetious about it?

[gegoune]

@l1n3n01z Without sounding negative/demanding - is that something you could come up with PR for? It would be greatly appreciated and accepted. I surely lack enough unicode knowledge to push it further.

[jdrouhard]

In the very least, please reopen this issue.

[l1n3n01z]

@l1n3n01z Without sounding negative/demanding - is that something you could come up with PR for? It would be greatly appreciated and accepted. I surely lack enough unicode knowledge to push it further.

I will have to read up on the contributing guidelines and in general how to do PRs on github, but I'm happy to.

[alex-courtis]

What is the appearance of the icons following grep 'icon = "' lua/nvim-web-devicons.lua?