feat: remap treesitter incremental selection not to collide with mini.ai#1992
feat: remap treesitter incremental selection not to collide with mini.ai#1992nathanzeng wants to merge 1 commit intonvim-lua:masterfrom
Conversation
|
Why is it called "remap"? I only see two new mappings being added. How does it compare to neovim's new builtin |
There was a problem hiding this comment.
great change, though I'm not sure about +/- for the keybinds.
I don't like the shift asymmetry between them (at least when using normal keyboards) - though they are easy to remember.
what do you think about aa/ii ?
ofc feel free to disagree. I will not force my taste in keybinds on everyone :)
|
|
||
| -- Treesitter incremental selection, see `:help treesitter-incremental-selection` | ||
| -- Note: the default keymaps `an` and `in` collide with mini.ai, so we remap them below | ||
| -- Try putting your cursor in one of the lines below and typing `v+` (then continue to type `+` or `-`) | ||
| vim.keymap.set({ 'x', 'o' }, '+', function() | ||
| if vim.treesitter.get_parser(nil, nil, { error = false }) then | ||
| require('vim.treesitter._select').select_parent(vim.v.count1) | ||
| else | ||
| vim.lsp.buf.selection_range(vim.v.count1) | ||
| end | ||
| end, { desc = 'Select parent (outer) node' }) | ||
|
|
||
| vim.keymap.set({ 'x', 'o' }, '-', function() | ||
| if vim.treesitter.get_parser(nil, nil, { error = false }) then | ||
| require('vim.treesitter._select').select_child(vim.v.count1) | ||
| else | ||
| vim.lsp.buf.selection_range(-vim.v.count1) | ||
| end | ||
| end, { desc = 'Select child (inner) node' }) |
There was a problem hiding this comment.
maybe this would fit better in the mini.nvim package spec?
That's the source of the conflict, and incremental selection is not exclusive to treesitter (it's also an lsp feature).
WDYT?
|
I'm glad you commented on the keybinds. I use
|
|
I feel conflicted about putting it in the mini package spec. It is true that the conflict is with mini, but the name of the relevant help doc is treesitter here. Also, we are exposing some lower level treesitter code here. If they were to make changes upstream in core that affects this code, it will almost certainly be labeled as treesitter so I do feel like there is reason to keep this in treesitter. |
|
TLDR: Should Personally, I don't use For a project like So the question remains: Is it worth working around a plugin, or should we simply remove it and rely on defaults instead? I realize this is a controversial suggestion, but addressing the issue from the |
3 participants
Treesitter incremental selection is pretty cool, let's make sure people have it right out the gate.
This PR requires neovim 0.12, and addresses an issue in #1971
These mappings are yoinked from core here