neovim: Support hats

[pokey]

[BlueDrink9]

Please forgive me for just dumping thoughts here: since graphical hats are going to be very difficult in a terminal based application, I think we could hack something functional together using virtual text and diacritics. A quick test with nerd fonts and the kitty app shows that pasting these diacritics works well even with arbitrary letters. They sometimes look quite funky with symbols though, often offset. I don't think there is support for coloring just the diacritics so we would have to color entire letters. Ugly, But I can still see this being pretty functional and offering a big boost to cursorless neovim functionality

[BlueDrink9]

I've been researching this some more and I think there are some ok options that we could build to move forward here other than diacritics. I'm mostly spitballing currently and dumping research notes, although I definitely have some appetite to move forward with this (but might need help plugging into cursorless from neovim to decide where the hat gets placed)

First, for the different shapes, other than the obvious option of using some closely matching nerd font character or unicode character, we could use a graphics protocol like the kitty graphics protocol to render the shapes properly. From my reading of the protocol, this would require us to convert the svgs two bitmaps and also probably embed the colors directly (i.e. have a folder, possibly a temporary one created on startup, that contains every shape in every one of the users colors.)

One useful thing that kitty graphics protocol allows you to do is render an image anchored to an empty unicode character displayed by the editor, including with offsets. This would probably be the most useful way to ensure that we track an actual character rather than having to consider the pixel positioning of the hats ourselves

We would use extmarks to create the unicode character as an invisible virtual text character overlaying or beside the target, and render the hats relative to that (i.e. above it, or even on it depending on the below workaround).
I believe, but I have not tested and it might not be the case, that you have to take up a full cell to render this character in order to display the image, so we could not display it over the top of an existing character.
In general, using a graphics protocol will become much easier once this API is created, and it is possible that it will also solve this issue.

Workarounds for placement of the hat:

1. Have a new virtual text line above every single line, that is purely for rendering a full sized shape (would waste a lot of space, but as a toggleable might be useful for some people. I would certainly consider this much better than nothing).
2. Wasting much less space, but a bit less intuitive to use, would be to render the unicode or hat to the right or left of every character. This would leave awkward gaps though unless we fill the gap with the hat itself.
3. We could render the unicode in the first blank character before or after the target, which would make it invisible but might have difficulties tracking the correct target depending on wrapping, and might be a lot more complicated to line up the relative offset with the correct target character. The same would go for rendering the character as invisible virtual text at the beginning or end of the line.
4. This is more radical, but we could potentially maybe pull the user's font and re render the every character with every possible hat and use that as the resulting unicode image, rendering that over the original target, but then it starts to probably get quite messy. Figuring out the users font might be quite tricky, so as a workaround that would probably be technically quite simple and functionally very complete, would be to pre render our own using just some random bitmap font. Would look ugly to the user having a random different font everywhere but that might be worth it for the added functionality. We could probably also include a script for the user to provide their own font that generates all of these.

My thinking is that 2 is easiest currently, rendered with the hat in the gap itself (i.e. over the virtual character). I would potentially also implement number 1 and 4, and have it as a user option.
As I understand it, the abovementioned future apis might just allow us to render the image at any point relative to a given character, without having to first render an invisible unicode character in that point. However that may not allow rendering between cells

No idea what the performance it would be of rendering a whole bunch of little images in the terminal, but if we can make them small bitmaps it might be ok...