Idea: highlighting parts of the documentation

[mikavilpas]

This week I have been working on a plugin at https://github.com/mikavilpas/blink-ripgrep.nvim. I want to build a way to quickly search matches for any text (with ripgrep), and inserting them in various ways.

Right now it looks like this:

As you can see, some context is shown in the documentation window. This works great for my needs, but it would be nice to see exactly where the matched word came from.

Compare to the way of highlighting the match that is available with telescope:

[Saghen]

Yeah sounds like something we can support. Just spit balling, but perhaps we could allow sources to hook into the documentation rendering so they can add whatever behavior they want. For example, I imagine it might be nice to include the entire file in the documentation preview and then scroll to the matched line. Feel free to open an issue and I can take a look

Plugin looks great btw! I'd love to upstream it closer to 1.0 if you're interested

[mikavilpas]

That sounds like a cool idea. I think allowing the sources to hook into documentation rendering will also be much more performant - for example 100 files can match the ripgrep search, but maybe only 2 matches need to be viewed in detail when the user hovers them.

And I'm open to upstreaming it too. I don't know if you have specific plans for testing, but I found the integrations with blink+neovim+ripgrep and the file system quite complex, and would recommend some testing setup to be in place.

[Saghen]

I think allowing the sources to hook into documentation rendering will also be much more performant - for example 100 files can match the ripgrep search, but maybe only 2 matches need to be viewed in detail when the user hovers them.

You can actually already achieve this with resolve which will be called before accepting the completion and showing the documentation. It's modeled off the completionItem/resolve function from the LSP spec: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#completionItem_resolve

Many LSPs will throw some LSP specific info in the data and then use it during resolve for performance

And I'm open to upstreaming it too. I don't know if you have specific plans for testing, but I found the integrations with blink+neovim+ripgrep and the file system quite complex, and would recommend some testing setup to be in place.

Totally makes sense, maybe we can look at this again after 1.0 in that case. Since we already have rust builds, I'd also be curious if we could throw rg into there 😄

[mikavilpas]

Since we already have rust builds, I'd also be curious if we could throw rg into there 😄

Hehe, this totally works and is actually incredibly performant thanks to good caching. I use it to compile yazi here, for example https://github.com/mikavilpas/yazi.nvim/blob/main/.github/workflows/test.yml#L33-L51 😄

edit: of course if you don't want to track the bleeding edge it will be easier to install a recent version with a normal package manager. 🙂

[mikavilpas]

By the way, another idea I have is supporting completing completing entire lines after a match is found (like https://github.com/amarakon/nvim-cmp-buffer-lines). I would ideally like to do only one ripgrep search over the current project for performance - so instead of two plugins searching the same codebase twice, it would only search once and allow completing two different things.

If you have some ideas how something like this could be supported, I'd love to know.

[Saghen]

By the way, another idea I have is supporting completing completing entire lines after a match is found (like amarakon/nvim-cmp-buffer-lines).

Sounds like a great idea! You can do this by using a textEdit instead of insertText/label and marking the entire line as the range: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_completion

A completion item provides additional means to influence filtering and sorting. They are expressed by either creating a CompletionItem with a insertText or with a textEdit. The two modes differ as follows:

• Completion item provides an insertText / label without a text edit: in the model the client should filter against what the user has already typed using the word boundary rules of the language (e.g. resolving the word under the cursor position). The reason for this mode is that it makes it extremely easy for a server to implement a basic completion list and get it filtered on the client.
• Completion Item with text edits: in this mode the server tells the client that it actually knows what it is doing. If you create a completion item with a text edit at the current cursor position no word guessing takes place and no automatic filtering (like with an insertText) should happen. This mode can be combined with a sort text and filter text to customize two things. If the text edit is a replace edit then the range denotes the word used for filtering. If the replace changes the text it most likely makes sense to specify a filter text to be used.

[Saghen]

Eventually, I'll also support the separate insert and replace ranges which you could also use to either insert the line or replace the existing line based on the user's preference/keybinding. Currently, the plugin always picks the insert range

[mikavilpas]

Oh I love this! A keybinding/default config of some kind could be incredible.

Now that I have my idea hat on, who knows - maybe this could be generalized and more completion kinds could be supported. It would be cool, for example, to complete an entire import statement with treesitter when the LSP refuses to offer it. Pretty exciting ideas!

[mikavilpas]

This is now well supported and everything is basically perfect 👍🏻 It works exactly like I wanted, so I'll close this as completed.