Closed tfachmann closed 3 years ago
Ironically I had just been thinking about this very use-case yesterday since I have a custom mapping for this without lsp integration. I'll try out an implementation this weekend. textDocument/references
is another lsp method with similar functionality where stuff by default goes into the loclist iirc so I might do something similar.
Gonna reopen cuz I haven't added documentation. Sample usage if you want to try it:
nnoremap <a-n> :lua require"illuminate".next_reference{wrap=true}<cr>
nnoremap <a-p> :lua require"illuminate".next_reference{reverse=true,wrap=true}<cr>
I've also recently uninstalled vim-matchup since this should largely replace it's functionality.
It's straight up beautiful @RRethy. Works like a charm.
Mention in the docs added.
This might not fit here, as this is obviously a plugin to highlight / modify what you can see on the screen, and not do searches or interact with the buffer as a whole. But with the integration of the LSP, I have thought of a use-case which I realized through your plugin.
consider this example:![screenshot-2021-01-15-134549](https://user-images.githubusercontent.com/35557890/104729070-2aa25980-5738-11eb-8305-9de7c979c63e.png)
I reassign
numbers
and the LSP knows about them being two different variables; therefore it is highlighted individually (which is amazing!). Same occurs if the scope changes, so ifnumbers
would be some function parameter.Therefore I have thought about the use-case, why not having a function to go to next occurence found by the LSP? Most of the time I just hit
*
and move through the results, but with an LSP integration, such movement could be much more clever (as well as avoid an unnecessary call tonohlsearch
).Would this fit here?