vim-illuminate VS nvim-treesitter-refactor

The vim-illuminate plugin offers the goto_next_reference() and goto_prev_reference() to navigate to next/previous reference of the word under the cursor.

vim-illuminate (https://github.com/RRethy/vim-illuminate) might be what you're looking for. It also has Alt-N/Alt-P mappings by default for jumping between matches.

You can add a prefix that's specific to your plugin, or just have a single field specific to your plugin's name which takes a table. Alternatively, in one of my plugins I use .configure strictly for configuration, which doesn't init the plugin, see https://github.com/RRethy/vim-illuminate/issues/112. The majority of configuration shouldn't be needed though if you have strong defaults, just look at tpope plugins.

Found it, vim-illuminate.

I think you're looking for vim-illuminate.

Does it do anything different from illuminate?

Ok, my guess is that you are using RRethy/vim-illuminate, xiyaowong/nvim-cursorword, or mini.cursorword. All of them use underline as default highlighting for word under cursor. And that you tried ellisonleao/gruvbox.nvim variant of Gruvbox, which doesn't explicitly support none of them.

setup is deprecated, use the opts table directly. Related stuff. Note that Leap is internally lazy-loaded anyway.

Maybe this? nvim-treesitter-refactor

These days though I'm using the https://github.com/nvim-treesitter/nvim-treesitter-refactor plugin. It goes one step further and only highlights the matches that are in the same scope. Makes a big difference in a lot of programming languages where you use the same variable named in a lot of smaller functions/methods right next to each other.

My desires are not sated, but it seems quite nice. (I recall treesitter-refactor has a similar scope highlighter, but it could be a bit aggressive near root scope -- this might be a more gentle version.

check https://github.com/nvim-treesitter/nvim-treesitter-refactor/

Treesitter performance is a hard problem. First, check the following: 1. Do you use nvim_treesitter#foldexpr()? Try not to use foldmethod=expr in insert mode. Or just switch to nvim-ufo. 2. Do you use nvim-treesitter-refactor's highlight_definitions or highlight_current_scope? These features do slower the performance. Try to disable these features. 3. I've heard some language parser is not good in terms of performance. Since I don't write haskell, I can't help you here. But you can create issue in nvim-treesitter.

For instance, with plugins like nvim-treesitter-refactor and ray-x/navigator.lua, you can use a bunch of commands like "go to definition" and "smart rename" without an LSP server.

TS Refactor

get_node_text was removed from ts_utils. create a pull request to fix it, something like this: https://github.com/nvim-treesitter/nvim-treesitter-refactor/pull/33

If you have treesitter, you can use nvim-treesitter-refactor. It has the highlight_definitions option that will highlight the definitions of a variable.

Oh! I've actually never tried Emacs text navigation. My brief stint with Emacs was with Spacemacs (w/ the evil-mode plugin). If I knew any lisp when I had given Spacemacs a whirl then there's a chance I may have stuck with it. I've played with Clojure a bit. Ah, it appears that you're a data-eng -- heavy on the Python. Are you trying to mimic something that PyCharm provides? I'm just happy that LSP has come where it has in such little time and that's already improved working with code in various languages quite a bit. Neovim moves incredibly fast and having LuaJIT with support for Lua had completely opened the floodgates for ports of old Vim plugins and made way for newer ones with floating windows/floating terminals. There are two projects each with hundreds of stars on GitHub meant to mimic or one-up org-mode (one has an entirely new spec) with immense development activity. The one-up that Neovim has over Vim presently is tree-sitter (because the core team wrote a wrapper) and exposes a Lua interface for plugin devs that want to use it. It's been neat for themes and my new favorite find-and-replace plugin (https://github.com/nvim-treesitter/nvim-treesitter-refactor). Because there's type data coming from the AST, it's much less likely to have accidental replacements (if at all). It looks like Emacs is making some headway here, though: https://github.com/emacs-tree-sitter