Re: No longer accessible host paths

[Michael Albinus]

JD Smith <address@hidden> writes:

Hi,

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

Yep. Alternatively, you could just load the tramp-cmds library. Or work
over the Tramp git repository (see below), where you have "make".

Next Tramp release in GNU ELPA will contain the new command out of the
box. Scheduled for end of November, but don't beat me if it is later ...

> As a summary, I was able to get rename-remote to work, but found the
> interface somewhat confusing.

That's what we're talking about :-) Every feedback is much appreciated!

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

Well, in my case it offers only connections opened in the recent Emacs
session. I've implemented this with completing-read, and I gave it an
own completion function, according to the completion machinery in Emacs.

Later on, you're saying you're using ido. I don't use ido, all what I
know about is that it bypasses the Emacs completion machinery. I guess
for the time being, we shall suppress ido (by let-binding ido-mode to
nil) when reading the source connection.

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

Again, ido must be kicked off here.

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

This includes the bad host name, which must be changed. And it would run
into problems, if a user (mistakenly) enters RET immediately, because
Tramp would start with actions in the bad host, which blocks Emacs possibly.

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

Here it shall work also with ido, there's no restriction is file name
completion anymore. But since I don't know ido, I would like to postpone
this problem; first it shall work on the default case.

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

I've added a predicate here, `file-directory-p'. Furthermore, I've
adapted the code that it doesn't matter whether you specify a directory
with a trailing slash, or not. (Technically, both source and target are
massaged by `directory-file-name').

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

Here I am undecided how to handle best. We have two options, call either
`set-visited-file-name', or `write-file'. The former just changes the
buffer's file name and marks the buffer as modified. The latter writes
the buffer contents to the new location.

I've decided for the first option, because it let you decide later,
whether you need to save this file really, or whether it is not
important enough to be saved somewhere else.

I understand that the default UI of interactive `set-visited-file-name'
is not convenient here. I will see whether I could write a wrapper
around. At least, it calls for proper documentation.

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

I believe it exists already. If you call `tramp-rename-remote-files'
while visitng a remote buffer, it should behave already like this. If
not, I will improve (I haven't tested this case extensively).

> 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

Yep, we must go through these case. But first, I want to have stable
ground on basic functionality.

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

I've just checked, there are still some few actions on badhost. Will see
how I could prevent them.

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

Well, the Tramp git repository is located at
git://git.savannah.gnu.org/tramp.git, see the Tramp manual. I have just
pushed some of the changes mentioned above, will continue to work on.

I would happily accept patches. However, Tramp is copylefted to the FSF,
which means every contributor shall sign the legal papers from the
FSF. Would you be willing to do?

Until this legal issue is solved, we can accept only contributions up to
~15 lines from the same person, in summary.

> JD

Best regards, Michael.