Make highlighting in info and signature help windows better

[leo-unglaub]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

Module(s)

mini-completion

Description

Hey,
first of all, i love your plugins, they are clean, easy to setup and work really fast. I love that. Thanks so much for providing them.

I noticed a small thing that might be an improvement. Right now the signature preview is in one color, buy with larger signatures it would be helpful to have them rendered with syntax highlighting on. It would, at least for me, improve the readability.

What do you think? Is that worth the work or not?
Thanks so much and greetings
Leo

[leo-unglaub]

Here is a better screenshot for a method that has a huge signature:

[echasnovski]

Thanks for suggestion and kind words!

This is interesting and might be doable. There are at least the following issues with it:

• I don't think it is guaranteed that signature help is a valid code of a language at hand. Thus it might not be good for parsing.
• Needs separate logic for initializing that highlight.
• This will introduce slight overhead because adding highlighting is not exactly immediate (needs parsing, etc.).

I'll think about it.

[leo-unglaub]

Those are some very well thought out concerns, you are right. My idea was as follows:

• Only do it if Treesitter is attached to the current buffer
• If its not valid code for the given language in the buffer, treesitter will fail very quickly
• Treesitter selectors could be used for still highlighting the current item
• There is a default debounce on this signature helper anyway, so it should be enought time for Treesitter to parse and render (beeing laggy would be horrible)

Greettings
Leo

[echasnovski]

@leo-unglaub, I've slightly repurposed this issue to be a bit more general. Hope, it's ok for you.

Note to self: in particular, make overall highlighting/visualization in both signature help and info window better. Think about (see #1426):

• Increasing conceal level for both of them.
• Figure out the source of "red DiffDelete-like highlighting of closing parenthesis" and how to adjust it.

[echasnovski]

I've finally got my hands onto this and it should resolved on latest main. It indeed ended up directly using tree-sitter highlighting if possible (same approach to highlighting as done in 'mini.files' and 'mini.pick' previews) and concealing helper characters (only in info window as it uses markdown).

There is also a more elaborate post processing of info lines received from LSP server which mostly concerns removing extra (usually unnecessary) whitespace.

The one downside of the current approach is that markdown code blocks appear as blank lines with tree-sitter enabled (which it is on Neovim>=0.10 as markdown parser is built-in) and they need to be present in order to have proper highlighting inside code blocks. This means that if info lines only contain a code block, it would have single empty line pads in top and bottom. I wouldn't say right now that it is a huge deal per se, but we'll see. There is a potential workaround of tweaking floating window dimensions computation to ignore top and bottom lines if they are code blocks, but this later requires a somewhat hacky vim.api.nvim_win_call(win_id, function() vim.fn.winrestview({ topline = 2 }) end) for every info window (to scroll past the possible first line indicating code block start). This is now resolved on latest main by adjusting window dimension computation and "hacky" scrolling. This became more visible after resolving #1258 in a way that shows detail in info window inside markdown's code block for a better highlighting. Having a single detail without documentation seems to be relatively common and having an info window be three cells high when it can be single cell high seemed to be too much.

@leo-unglaub, oh, but I believe this would still not really improve signature help highlighting in PHP, because those need <?php first line to work properly (I think, as I don't really know much about PHP). As LSP server doesn't use that, there is no highlighting. As special casing certain non-Neovim-adjacent languages is a big no-no in 'mini.nvim' (might be possible but for strong cases), I don't think handling that automatically in 'mini.completion' will be possible.