Inlay diagnostics are not colored on a Rust attribute invokation with multiple lines

[raiguard]

I ran :echo -debug %opt{lsp_diagnostics} and the markup strings were there, but as you can see, the inlay diagnostic is not being colored. In my testing, it only happens in this very specific circumstance: When you use an attribute whose arguments are split onto multiple lines.

Reproduction:

1. Insert the following into a Rust program:

   #[drive(
   // Foo
   Debug,
   )]

2. Observe that the inlay diagnostics on the first line are uncolored

[krobelus]

I didn't track it down but this must be a conflict with a rust highlighter, since it works after remove-highlighter window/rust.

The implementation of inlay hints feel too complex. What if we used a flag-lines highlighter instead (is it possible to have it display on the right border?) Then we wouldn't have problems like this, same for the weird jumping when it's enabled in insert mode (and if we can't fix that we should document a way how to enable it only in normal mode).

[sclu1034]

My initial guess would be "order of highlighters" as well, although I believe it's semantic highlighting rather than shared/rust here, since the built-in rust.kak is quite simple when it comes to macro attributes.

With all the inline stuff that kak-lsp has, it is quite complex to keep track of the order. One way to test that would be executing

remove-highlighter "<scope>/lsp_diagnostics"
add-highlighter "<scope>/lsp_diagnostics" replace-ranges lsp_diagnostics

(where <scope> is either global or window, depending on what scope you enable LSP in). That should force the diagnostics highlighter to execute last and override everything else.

---

The problem with flag-lines is that it uses entire columns. It would immediately reserve a huge portion of the window, even if there's only a single message.

Ideally, there would be a way to hide inline diagnostics in insert mode for just the lines around the cursor. But I'm not sure if that can be done efficiently with kakscript. It might need a flag on the replace-ranges highlighter.

[raiguard]

Yeah, unfortunately, there is no way to use flag-lines to draw on the right side of the buffer.

Neovim has the advantage here, because they implement these using virtual text, which is completely separate from the buffer contents and other highlighters. If we got the ability to specify end-of-line virtual text, all of the issues surrounding the inlay hints could be solved. It would require a new highlighter though.

[raiguard]

Here's another good one. Strange that the ranges take priority over markup strings.

[sclu1034]

That one definitely looks like the syntax highlighter was created after the diagnostics highlighter.