feat: add rename with substitute command

[Uanela]

Motivation #3328

I found this feature on Oil and at least for me this was/is the main reason I use Oil, the first one was visual operations like copy/delete/cut and so on, but this one was missing, basically allowing :%s/old/new to change nodes names renaming and writing to disk.

Changes

1 - Added M.bulk_rename into rename-file.lua
2 - Added opts into M.rename to prevent notifications as it is used on a loop
3 - Added opts to get_visual_nodes to correctly allow using '<,'> when needed
4 - (Not quite sure where to put yet or organize), Added an autocmd for watching ex commands

Features

1 - :%s/old/new will select or visible nodes and a simple prompt to rename (substitute) if yes they are written to disk
2 - :'<,'>s/old/new works the same way but on the visual selected part

Concerns

1 - Where and how should the new ex commands autocmd be devided?
2 - Should the autocmd of ex commands stay? or instead create at dedicated something like NvimTreeSubs or whatever to put the tree into substitution mode? - first approach is more natural and expected

I am quite sure that there is a lot of work regarding code organization here, will just wait for your suggestions.

[v3ceban]

I considered adding something like this in my initial implementation of bulk ops, but ended up not to due to complexities of renaming directories, nested structures, and converting files <-> dirs. If this only targets files I imagine it should be good.

It's missing the mappings to actually try it out, but the logic looks good to me. There are no regressions with existing bulk ops.

I'll leave organization questions for the core maintener to decide on.

[v3ceban]

Good catch

[alex-courtis]

This is looking very promising.

I'm not quite sure how to test this. Do I add something like this to API impl? Not sure what the other arguments should be...

api.fs.rename_bulk                           = _v(function(n) require("nvim-tree.actions.fs.rename-file").bulk_rename(n) end)

Please:

• move the autocommand to rename-file.lua
• add API, doc and keymap

[alex-courtis]

Firstly, I apologise for the state of autocommands. Having them all in one place is not desirable, and was done purely for startup performance.

Fortunately, this does not have to be a global - it can be placed in it's correct place - rename-file.lua

It can be created when needed i.e. user invokes bulk_rename and removed once the operation is complete. We could probably automatically clean it up after it is done via the {once} option of :help nvim_create_autocmd(). See help.lua for an example.

[alex-courtis]

rename-file.lua already has these, so we should be able to remove these lines 🤞

[Uanela]

Thanks for you quickly review @alex-courtis.

The purpose of this PR is to allow the user to simply do :%s/old/new on nvim-tree buffer and rename files as if he was on a normal buffer writing text.

We what I said above the autocmd must be listening all the time when the user enters nvim-tree buffer, this will cause the substitution operation feel natural and pleasant. If it is not intended to let the autocmd listening full time we can put nvim-tree in what we can call our own substitution/whatever mode which will require him to then be prompt old: currentthing then new: newthing or something similar.

I personally choose to go with autocmd listening full time (or better when enters nvim-tree buffer) to give as native as possible behavior and what user might expect, and this is exactly what I mentioned on #3328 (comment).

[alex-courtis]

I personally choose to go with autocmd listening full time (or better when enters nvim-tree buffer) to give as native as possible behavior and what user might expect, and this is exactly what I mentioned on #3328 (comment).

Apologies, I did not Seek First To Understand.

That's a really natural and intuitive way to present this feature.

Edit: accidentally closed the PR. It's open again.

[alex-courtis]

This is looking great, it's working exactly as advertised: visual range, patterns, closed directories

The UX is natural and good; the user is informed before changes with the number, to avoid any accidents.

1 - Where and how should the new ex commands autocmd be devided?

Not sure what you're asking here - do you mean the / delimiters?

2 - Should the autocmd of ex commands stay? or instead create at dedicated something like NvimTreeSubs or whatever to put the tree into substitution mode? - first approach is more natural and expected

Yes to ex as discussed.

• reduce autocommand scope

Using a global autocommand for CmdlineLeave is quite scary - none of my installed plugins do anything with that event, except for vim-asterisk which is a hacky old vim plugin.

Proposal:

• use a buffer local autocommand attached to the nvim-tree buffer, similar to open-file.lua and help.lua.
  On review, it seems that buffer local is not practical today, as View owns the buffer, not Explorer. Once multi-instance is completed and ownership moved to Explorer, it can changed to a buffer local.

• put this autocommand in the Explorer.augroup_id, which will ensure that it is created only when needed and then cleaned up

• you can create the autocommand during Explorer:create_autocmds()

• investigate native vim substitute

Rather than applying the substitution ourselves via gsub, could we let vim execute the patterns/magic etc. for us via vim.fn.substitute?

I'm looking at the API and Nvim source and not finding any means for vim to execute a s/foo/bar/g against a string, only a buffer. I did have hopes of some sort of vim.fn.sub(node.absolute_path, 's/foo/bar') however that just doesn't exist as it's buried in the c code.

• wild and crazy - vim does all the work in a scratch buffer

This may not be practical at all.

• Write all the paths from a string table to a scratch buffer
• Execute the user's vim.cmd.substitute('s/foo/bar/g') against the buffer
• Read the scratch buffer to a new table
• Rename all paths that have changed

[Uanela]

I just tried /some-text and then d should we add this and change the PR title to feat: add search and substitute operation?

[alex-courtis]

I just tried /some-text and then d should we add this and change the PR title to feat: add search and substitute operation?

Nice, this can really be a general :substitute feature.