Implemented VI mode change inside and delete inside functionality

[ayax79]

This implements the change in (ci) and delete inside vi mode functionality:

• ci" - Change in quotes
• di" - Delete in quotes
• ci[ - change in brackets

supports [ , ( , ", ', `, {

[sholderbach]

Thanks, such a nice convenience of vim to have!

There are certainly some mismatches we will still have due to the clunky event translation (like not advancing to the text object if before or multiplier and redo things that may need some tweaking but that probably needs a rework outside the scope of one PR)

[blindFS]

I was waiting for this feature for long. It made me curious about the future plans for nushell repl parser/highlighter, are we going to use treesitter here in reedline in near future? Since without AST info, it's hard to deal with nasty cases where brackets get nested like (foo(bar "(" ) baz)

[sholderbach]

Looking good to get that going, in principle the i{char} text object parsing could also move to the motion parsing part. The command logic should preempt to insert mode before it is interpreted as a traditional motion. But the gain from that refactor is not as big yet as we only have d and c accepting motions at the moment.

[sholderbach]

I am thinking you could save yourself some duplication here by doing the conversion to the one bracket side when creating the Change/DeleteInisde(char) but then there would be also something to watch out for correctness.

[ayax79]

I would still need to know if it is a right of left side bracket to get the ordering right.. It felt cleaner to have be a separate match statements. I did collapse the Delete and Change conditions together since they were inherently the same.

[ayax79]

Another thing that should be addressed at some point.. Since this is basically supplying two actions, it requires two undo commands to get back to the previous state.

[bishopmatthew]

I was waiting for this feature for long. It made me curious about the future plans for nushell repl parser/highlighter, are we going to use treesitter here in reedline in near future? Since without AST info, it's hard to deal with nasty cases where brackets get nested like (foo(bar "(" ) baz)

+1 to that — I didn't realize someone was already working on this and had started looking into how one might implement the full set of vim text object operations...

The basic pattern is where:

Operation is something like d (delete), c (change), y (yank/copy), v (select)
Scope is either i (inside) or a (around)
Text object can be things like w (word), p (paragraph), ( (parentheses), " (quotes), } (curly braces)

Anyways — it seems like the way to be able to implement all of this stuff in a consistent way would be to use tree sitter.

• reedline could be more useful to other shells since support for other languages
• what @blindFS mentioned about handling complex nesting — actually it seems like maybe you've already started on improving https://github.com/nushell/tree-sitter-nu in support of this?

[blindFS]

@bishopmatthew tree-sitter-nu's accuracy has been improved recently on its own. Feel free to report any parsing error or WA. As for the integration to reedline, I think it's not planned yet, and a general set of api to process ast/cst would be a better option on second thought. Using treesitter may not be the only option since it needs extra overhead compared to the native parser.

Actually there's a hacking way (in case you want the functionality right now) for limited textobj related ops with current reedline implementation: mapping to user defined command with internal ast and commandline for the dirty job.