On Nov 13, 2019, at 10:15 AM, Michael Albinus <[email protected]> wrote:
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
