Re: No longer accessible host paths

[Michael Albinus]

JD Smith <address@hidden> writes:

Hi,

> Impressions of `tramp-rename-these-files` (which I think you made at
> my prompting… thanks!):
>
> * 1st Prompt:
>
> * Ido really works poorly with this style prompt, but a simple C-f
>   gets you to a normal completion.

I fear this is nothing I can fix. I don't use Ido, I don't know
Ido. Somebody else might contribute patches.

> * 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.

It is intended that the old host does not give useful information
anymore. Any file information must be retrieved on that host, but it is
likely not reachable anymore.

It might be helpful to improve the error message, but it's not simple. I
have added a comment about this.

>   Also their old source host may still be valid (e.g. just changing
>   method).

Of course. As soon as you change one letter in the method (for example,
from "ssh" to "sshx", the tramp-ignored-file-name-regexp restriction
does not apply.

> * 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.

Good idea. Done.

> * 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).

Done.

> * 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?

There could be several buffers with a buffer-file-name matching the
renaming. Some of them might have been forgotten by the user. Therefore,
in order not to get surprises, the renaming shall be confirmed by the
user, as default. If this is not intended, we have NO-CONFIRM.

Furthermore, I plan to implement a local quit. That is, if
`set-visited-file-name' offers you a change, and you don't want to apply
it, you hit `C-g', and the renaming of *this* buffer's file name is
cancelled. The next renaming will be offered, then.

> * 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.

Well, maybe we need another user option in order to distinguish the two
confirmation cases. `tramp-confirm-rename-file-names', if set to t (the
default), triggers the confirmation of `set-visited-file-name'. A value
of nil doesn't ask for. The NO-CONFIRM argument is not needed anymore,
we just use the prefix argument of the command to avoid confirmation of
the target path.

I've implemented this; you might play with.

>     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.

Such a buffer could be a directory listing, or the output from a remote
process.  In general there shouldn't be a problem with, when the buffer
is not touched. What I worry about is `revert-buffer', which could
restart a remote process. In some cases, this command could be triggered
with a simple "g", which can be typed easily by accident ...

I will check further what to do.

> 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).

Adapted.

> 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?

I've tried to find proper wording for this.

>     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”))

Add a trailing colon ":", and you have a directory name.

> 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?

This I don't understand.

> 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.

Yes. This is a long standing problem, to avoid Tramp blocking whole
Emacs. I haven't a general solution yet, because it does not depend only
on Tramp.

Last year, I've started to bring asynchronous file operations to
Tramp. But this work is stalled, due to problems with threads in Emacs.

> Otherwise this looks great.  Thanks again for your work on this.
>
> JD

Best regards, Michael.