-
-
Notifications
You must be signed in to change notification settings - Fork 639
Conversation
@v3ceban
v3ceban
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch
@alex-courtis
alex-courtis
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename-file.lua already has these, so we should be able to remove these lines 🤞
Uanela
commented
Jun 22, 2026
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).
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 toopen-file.luaandhelp.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
commented
Jun 25, 2026
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
commented
Jun 25, 2026
I just tried
/some-textand thendshould we add this and change the PR title tofeat: add search and substitute operation?
Nice, this can really be a general :substitute feature.
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_renameintorename-file.lua2 - Added
optsintoM.renameto prevent notifications as it is used on a loop3 - Added
optstoget_visual_nodesto correctly allow using'<,'>when needed4 - (Not quite sure where to put yet or organize), Added an
autocmdfor watching ex commandsFeatures
1 -
:%s/old/newwill select or visible nodes and a simple prompt to rename (substitute) if yes they are written to disk2 -
:'<,'>s/old/newworks the same way but on the visual selected partConcerns
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
NvimTreeSubsor whatever to put the tree into substitution mode? - first approach is more natural and expectedI am quite sure that there is a lot of work regarding code organization here, will just wait for your suggestions.