Hi,
FTR, I've renamed the functions to `tramp-rename-files' and
`tramp-rename-these-files'. This seems to fit better the purpose, I
believe.
If there are no serious complaints, I'll merge them to Emacs 27.0.50
over the weekend. Bug fixing will still be possible, there's even no
pretest of Emacs 27.1 yet.
Thanks. I gave a try and will continue over the next week or so.
Impressions of `tramp-rename-these-files` (which I think you made at my prompting… thanks!):
- 1st Prompt:
- The interface here seems good in terms of the “from path” being hard coded, and the “to” path then being editable, with both being visible at the same time.
- Ido really works poorly with this style prompt, but a simple C-f gets you to a normal completion.
- When I do try to edit the local directory path part of the name first, I get [No Match] or [Not Readable] errors, presumably because the `file-directory-p` predicate is trying to find out if the text entered is a directory, but the host is already being ignored by tramp (due to the let tramp-ignored-file-name-regexp). I see the point of that (it’s a bad host after all), but I think it will confuse people, since it’s kind of a vague error. Also their old source host may still be valid (e.g. just changing method).
- Since the host *must* change first to ever have a chance to satisfy the `read-file-name` predicate (with tramp ignoring the current buffer’s host), perhaps point in the mini buffer should be placed at the end of the host part to start.
- Also, you could consider switching required from t to ‘confirm in `read-file-name`, so that someone can overrule the predicate if they really know what they are doing (e.g. a network pathway is still being established).
- 2nd Prompt:
- What I don’t understand here is why, after the 1st prompt of rename-these-files, I get a 2nd prompt “Set visited file name” at all. Should that not have already been taken care of by the 1st prompt, which included the longest common prefix for all files on method:host? I.e. if I didn’t change the local file directory in the 1st prompt, why would I be asked again with a 2nd prompt if I want to?
- So in my opinion, interactive calling of set-visited-file-name seems like an unnecessary and confusing duplication. If I wanted to change the file *name* itself, I could first change the host and directory using tramp-rename-these-files, then C-x w it easily enough. I can’t think of a changing network scenario which would require the *filename* to change. It seems to me just (set-visited-file-name buffer-file-name) should suffice for all reasonable scenarios.
- Then no-confirm can apply to just one thing: the default-rename-alist. Right now there is no prefix or no-confirm based method to call change-these-files that avoids the unnecessary final `set-visited-file-name` prompt.
One point I'm still undecided are remote buffers NOT visiting a
file. Shall we change their default-directory to the new target
directory, when applying one the the `tramp-rename-*' functions? This
could result in unexpected behaviour, I fear. Alternatively, we could
delete respective buffers (with confirmation, if NO-CONFIRM is nil).=
I didn’t think about a remote buffer which is not visiting a file. Is this for directory listings for example? I doubt deleting such buffers would be expected behavior. What sorts of issues do you envision by changing default-directory? To me it seems the most consistent to reset all instances of the bad remote path, whether visiting a file or not.
A few comments on the docs:
+In such cases, the command @code{tramp-rename-files} could be used to
+save buffer contents of remote buffers somewhere else.
Given that these commands don’t actually save the file, perhaps better would be:
In such cases, the command @code{tramp-rename-files} can be used to
alter remote buffers’ method, host, and/or directory names. This permits saving their contents in the same location via another network path, or somewhere else entirely (including locally).
Also:
target is selected from tramp-default-rename-alist without confirmation when called interactively, and applying set-visited-file-name is also performed without confirmation.
This method of rename presumably works only if there is a match in tramp-default-rename-alist, yes? Perhaps it’s worth mentioning that the prefix argument does nothing unless a match in the alist actually occurs? Or is it an error?
The first matching item specifies the target to be applied for renaming buffer file names from source via tramp-rename-files. source is a regular expressions, which matches a remote file name. target must be a directory name, which could be remote.
Why must target be a directory name, can it not be *just* a user@method:host path? I.e. what would be wrong with an alist entry like:
‘((“/ssh:oldhost” . “/ssh:hophost|ssh:oldhost”))
In fact from your examples it seems this should be possible (btw, love the %u & %h with a regex: very powerful!). Also, is the final colon required on host-method only renames?
I do note that if you mess up a rename, accidentally using an unreachable hostname, Emacs freezes with “Waiting for prompts from remote shell…”, and sometimes doesn’t time out. This isn’t actually new behavior, just somewhat easy to trigger using these bulk renames. Often no amount of C-g’ing stops it, and you must kill Emacs (possibly with a USR2 signal, which recovers it). This likely has nothing to do with renaming. It probably has a lot to do with my need for the rename functionality you’ve added.
Otherwise this looks great. Thanks again for your work on this.
JD