Virtual text (text annotations) support

[sudormrfbin]

Similar to neovim's virtual text feature (greyed out faint text at end of lines in the image):

This would enable having indent guides, inlay hints (useful with rust-analyzer), inline diagnostics messages, etc. Being able to place virtual text in between normal text would also be nice.

I have a general idea as to how to do it, I'll take a stab at it.

[archseer]

I think this might be a bit tricky right now, but we've had discussions with @cessen on how to support these type of inline "decorations". Vim only supports these at the end of line, because placing them inline affects on-screen positioning calculation.

The way I imagine this working is that it would be a character offset pos, the text and a style. The render loop would then need to handle these injections and any sort of visual positioning calc then needs to account for these.

---

Indent guides: I'm not sure if those should be virtual text or just special rendering code for certain characters.

I like this behavior in vim:

" show whitespace with <leader>s
set listchars=tab:——,trail:·,eol:$,space:·
"set listchars+=extends:›,precedes:‹,nbsp:␣
nnoremap <silent> <leader>s :set nolist!<CR>

This way I'm able to toggle a "MS Word-like" view where spaces and certain other chars are visualized.

[sudormrfbin]

Cursor position calcuation and rendering seems like the only problematic part of the implementaion, but I'd say it's doable with some careful thought.

I think indent guides are better implemented as an application of virtual text rather than as a special case (plugins can then tweak it if required too). listchars like behavior can also be done using the same mechanism. I imagine there will two ways to display virtual text:

1. Inject text after a particular offset. This can be used for inlay hints, and the cursor will move "over" them when using motions (you can't place the cursor on these character).

2. Replace existing text. This can be used for listchars and indent guides. The cursor can be placed over them and editing operations will simply act on the actual text.

If we have a namespace mechanism for grouping together different decorations, then toggling indent guides or listchars will be easy too.

[cessen]

This is definitely doable, and something I think we all want Helix to support. I would suggest holding off on implementing right now, however, as it will likely be wasted effort. The rendering system is likely to get an overhaul in the not-too-distant future, to support not only end-of-line annotations but also inline annotations, word wrapping, etc.

Edit: ah, looks like you already got started. I suppose an initial implementation could figure out how to get the information to the rendering system, which likely won't be thrown away with the rendering overhaul, at least.

[valpackett]

I really like how this is done in Kakoune:

add-highlighter global/line-nums number-lines -relative -separator ' '
add-highlighter global/unicode-whitespace show-whitespaces -tab '▏' -nbsp '␣' -spc ' '
add-highlighter global/soft-wrap wrap -word -indent -marker '↪'

show whitespace (listchars), line numbers, soft word wrap — everything that modifies visual output is a "highlighter". Plugins like kak-lsp do inline diagnostics like that as well.

[Krahos]

This is definitely doable, and something I think we all want Helix to support. I would suggest holding off on implementing right now, however, as it will likely be wasted effort. The rendering system is likely to get an overhaul in the not-too-distant future, to support not only end-of-line annotations but also inline annotations, word wrapping, etc.

Edit: ah, looks like you already got started. I suppose an initial implementation could figure out how to get the information to the rendering system, which likely won't be thrown away with the rendering overhaul, at least.

Where can I track the progress on rendering overhaul? I'm really looking forward to have type annotations for Rust, similar to what VSCode does with Rust Analyzer.

[sudormrfbin]

It's not currently tracked anywhere at all, and the work itself would be quite involved, i.e. there's no ETA yet.

[cessen]

Ah yeah. I was going to take on the rendering overhaul myself, but have since stopped really contributing to Helix due to time constraints, interest, etc. (Although I'm still an active user.) So realistically, unless someone else takes it on, it's probably not going to happen.

So it probably doesn't make sense to wait on it anymore.

[poliorcetics]

I personally dislike inline annotations (bar indent guides) so if this is added, I would like the option to force everything to be at the end of the line (for example in the case of rust, display final type of the line and diagnostics but not parameters hints in between code)

[cessen]

I personally dislike inline annotations

Speaking as a user, I actually agree. Ha ha.

Another possibility, which would likely be easier to implement anyway, would be to have annotations between lines. This would keep the code from jumping around horizontally, at least, and would provide room to optionally expand e.g. error messages. Not sure if I would actually enjoy that any more than inline annotations in practice, but it seems like a simpler and more practical way to achieve what's actually important about inline annotations, functionality-wise.

[hunger]

I actually like the inlay hints in the place where they are relevant and not just appended to the end where I have to figure out myself where those are supposed to go!

But for me it is critical that the inlay hints are very obviously not code that is actually there. In VSCode that is nicely handled by using a smaller font. In Vim I configured "real" text to be rendered in normal font while all virtual text is in italics. That works well for me -- but then vim can not render inlay hints inline either and appends.

[poliorcetics]

I don't think we were saying to ban only hints, don't worry ! We just want the option not to have them come in between code, but all possibilities should be available, that way everyone can get what they want :)

[talk2drys]

having inlay hints at the end of the line looks alright, this way it doesn't really mess with code layout

[dekuraan]

Is that a working branch with type hints or is that just a mockup?
Also is there any way I can help with development of this feature?

[pascalkuthe]

This didn't get tagged appropriately but with #5420 merged the infrastructure for virtual text (inline, overlay and multiline) is now available in master so this issue can be closed.