Great, thanks. I took a look. For those of you following along, I had to add the following to tramp-loaddefs.el to have the new `tramp-rename-remote-files` command available through the normal (patched) ELPA package:
(autoload 'tramp-rename-remote-files "tramp-cmds" "\ Replace in all buffers `buffer-file-name's SOURCE by TARGET. SOURCE is a remote directory name, which could contain also a localname part. TARGET is the directory name SOURCE is replaced with. Often, TARGET is also a remote file name on another machine, but it can also be a local file name. On all buffers, which have a `buffer-file-name' matching SOURCE, this name is modified by replacing SOURCE with TARGET. This is applied by calling `set-visited-file-name'. The buffers are marked modified, and must be saved explicitly. The remote connection identified by SOURCE is flushed by `tramp-cleanup-connection' unless there still exists buffers with a `buffer-file-name' pointing to this remote connection, or unless KEEP-CONNECTION is non-nil. Interactively, KEEP-CONNECTION is set to the prefix argument." t nil) As a summary, I was able to get rename-remote to work, but found the interface somewhat confusing. > On Nov 8, 2019, at 10:01 AM, Michael Albinus <michael.albi...@gmx.de> wrote: > > Michael Albinus <michael.albi...@gmx.de> writes: > > Hi, > >> I hope to have a first version of tramp-rename-remote-files ready this >> week, for playing. I would post a patch here, on top of Tramp 2.4.2.4. > > I have implemented a very first shot, see appended patch. It is pretty > much alpha, it needs more careful testing, and it represents just where > I stand now. Improvements welcome, but stabilization first. Proper > documentation is also missing. > > You can apply this patch on top of Tramp 2.4.2.4 from GNU ELPA. I guess > it would work also on top og Tramp 2.3, but I haven't tested yet. > > The scenario I have tested so far is: > > - I have some open buffers with files located in /ssh:bad:/tmp. I > believe this connection is broken, so I call "M-x tramp-rename-remote-files" > > - "Enter old connection: /ssh:" > I complete this via TAB, until I have the remote connection "/ssh:bad:" This sort of works, but proposes *all* the hosts ever visited, not just those in current buffers. > - Now, the next TAB gives me the longest common path of all buffers > connected to /ssh:bad: - this is "/ssh:bad:/tmp/". Works (but not really in ido). > - After RET, I get the prompt "Enter new Tramp connection: /ssh:". The > Tramp method of the old connection is offered as initial completion. Here it would make far more sense to me to have the full string from the old connection initially, since tweaks are often small. > - Via usual minibuffer completion, I have "/ssh:good:/var/tmp/". I > confirm this with RET This works (but not with ido, which doesn’t understand this is a file prompt). The real issue is by now I’ve already forgotten exactly which initial string I am replacing. Does it end in a “/“, a “:” (if host only)? Too many chances to mess up. > - Now, the command goes through all buffers. Buffers which have a > buffer-file-name starting with the old name, "/ssh:bad:/tmp/", are > presented to me, plus the prompt "Set visited file name: > /ssh:good:/var/tmp/". Confirming this with RET, sets the new > name. This is editable, of course. Also confused here. Is this not a new file but a *new* path to file? I entered “file.txt” here, which was interpreted as a directory, leading to auto-save errors for directory “file.txt/“. If it is a new file *path*, it seems redundant with the search-replace of the longest common prefix string. > Well, that's it. The buffer file names are renamed, the buffers are > marked modified. Now you can save them (or not :-) When I did make it this far I was pleased to be able to have switched hosts. I do think perhaps a simpler `tramp-rename-this-remote-file` which just give you the /method:host:file prompt and lets you edit it would be a useful addition. Maybe it helps to list out typical use cases. Here are the uses I envision: Just One File: /method:badhost:/path/to/fileA -> /method:hophost|method:goodhost:/path/to/fileA Two or More Files on Same Host: /method:badhost:/path/to/fileA, /method:badhost:/path/to/fileB -> /method:hophost|method:goodhost:/path/to/fileA, /method/hopost|method:goodhost:/path/to/fileB One ingredient I haven’t yet tested is when the badhost is truly inaccessible, does it still hang if you forget to run rename-remote first (which seems inevitable to me). Can try that later. > Happy testing! Any feedback is more than welcome. Thanks for your work on this. BTW, is this tied to a git repository somewhere so I could propose code edits? JD
