Render private unicode symbols as double width if followd by space separators (plain space, nbsp, en space, etc.)

[Bekaboo]

Is your feature request related to a problem? Please describe.

Firstly I would like to express my thankfulness to Kitty for addressing this specific case of fzf-lua where a nbsp (it is actually not, see below) instead of plain space is put after nerd font icons as separators.

The author of fzf-lua calls it nbsp, but it can actually be any non-printable character and is default to "EN space" U+2002, the goal here is that the character should not appear in normal text files. For more information about the hack see:

https://github.com/ibhagwan/fzf-lua/blob/04e7382528f3f4970cb1cd559d06ae6f7b44560e/lua/fzf-lua/utils.lua#L24

Given the list of unicode space characters, could we treat all the (17) characters the same as normal space when deciding the rendering width of nerd font icons?

Describe the solution you'd like

Take all 17 space characters, not only nbsp (U+00a0) into consideration when rendering private unicode symbols.

Describe alternatives you've considered

N/A

Additional context

N/A

[kovidgoyal]

I dont want to do all space characters since being able to use some space characters to force kitty to render symbols in a single cell while being followed by a visual space is an important use case. So if nbsp is not suitable, pick another character that you need. En space is fine by me. Although really the correct fix here is for fzf-lua to not rely on such a hack.

[Bekaboo]

Thanks for replying.

I dont want to do all space characters...

... So if nbsp is not suitable, pick another character that you need. En space is fine by me

Does this mean taking EN space into consideration is fine but adding all 17 space characters is cumbersome for you?

[kovidgoyal]

On Tue, Oct 24, 2023 at 08:26:59PM -0700, Shihua Zeng wrote:

Thanks for replying.

I dont want to do all space characters...

... So if nbsp is not suitable, pick another character that you need. En space is fine by me

Does this mean taking EN space into consideration is fine but adding all 17 space characters is cumbersome for you?

It means I am fine with two such characters, regular space and something else. Currently that something else is nbsp if you prefer it to be enspace, I am OK with that. I might even be OK with allowing three rather than two such characters, however that should be unneccessary. In general, the less magic there is, the better :)

[Bekaboo]

In general, the less magic there is, the better :)

I completely agree with this viewpoint. Unlike other fuzzy finders such as telescope.nvim, which has seamless integration with nvim and can pass data through Lua table structures, fzf-lua operates within a real fzf terminal buffer. In this context, messages can only be transmitted as strings, necessitating the use of special characters to distinguish icons from actual filenames or locations. It's a bit of a workaround, but it does get the job done. Unfortunately, I can't imagine any alternative solutions to this issue. (One might ask why not use telescope.nvim then, but being less integrated with nvim and using a real external fzf process has its advantage that it never blocks nvim event loop and can be much faster and responsive when dealing with large repos.)

So according to your reply we have two options:

1. Replacing nbsp with En space
2. Adding En space besides nbsp but not other unicode space characters

I personally prefer the second solution but it's not that tidy (yes I know). What is your opinion?

[kovidgoyal]

What exactly does fzf-lua require? nbsp or enspace or both or either?

[Bekaboo]

@kovidgoyal En space (by default, since nbsp is more likely to appear as content in text files). It is configurable but I can't see any reason for user to change this value if kitty support rendering full-width icons followed by en space out of the box.

[Bekaboo]

Thanks, works great!