nvim-treesitter-textobjects
nvim-treesitter-textobjects copied to clipboard
nvim-treesitter
Support Operating Pending Mode with Motions
Is your feature request related to a problem? Please describe.
Support an operator-pending mode for moving through the textobjects (e.g. 3]f moving 3 functions down)
Additional context I know this has been brought up several times. However, it seems to be completely ignored in each issue.
Could I at least get a status update on this issue, advice for how to implement it myself, or an outright denial of adding this feature? A lot of people seem to be sitting on it.
Any news on that, is it that hard to implement into the existing code base ? Isn't it just about reading vim.v.count1 and looping over and move that many times in that direction ? That should also apply to select as well, not just move. At the moment you cant do 3daf for example
Well, the we originally wanted to re-architect nvim-treestitter-textobject to use nvim's query API directly which would avoid performance issues. nvim-treesitter-textobject uses an old abstraction layer (the logic is primarily in nvim-treesitter) and a lot of features got hacked around that abstraction layer. This kind of lead to a code freeze especially in select as the refactor never happened. A lot features were just special-case integrated by non-member contributors which made the the implementation unnecessary complex.
I've tried to implement this feature about more and year ago. It was not that trivial and I found the complexity not worth it to integrate it in the current implementation. I told myself that I'd rather refactor the helper functions in nvim-treesitter to search for multiple textobjects directly.
But I'm open to contributions that'd add the feature using the current code base.
Right, gotcha. Okay, given the current code base what are the negatives of simply repeating the action for example. Looking at the implementation, there is a way to make use of v:count1 and just loop over the relevant piece of code that drives ts.goto_node. Is that a feasible solution, until the more substantial refactoring takes place ?
