tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No longer accessible host paths


From: Michael Albinus
Subject: Re: No longer accessible host paths
Date: Mon, 04 Nov 2019 09:34:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

JD Smith <address@hidden> writes:

Hi,

[pls keep address@hidden in Cc. I'd appreciate comments also from
other users]

>> Well, I'm still playing with scenarios. For the time being, I have
>> called the function `tramp-rename-all-buffer-files' (but I'm not fixed
>> on this name). The idea is to rename a prefix by another prefix for
>> buffer-file-name in all related buffers, and let the user confirm that
>> choice for every matching buffer. The interactive case would be
>> 
>> M-x tramp-rename-all-buffer-files
>> Enter old Tramp connection: /method:badhost:
>> Enter new Tramp connection: /method:newhost:
>
> You could consider prompting with the longest prefix common to all
> files being visited on badhost.

But badhost is just a guess, based on a possible current-buffer with a
remote default-directory. If the current-buffer isn't remote, the
initial value must be chosen from the different remote connections which
exist. There can be several ones.

And if it is the wrong guess, you need to edit the proposed initial
value. So you would also need to remove the "longest prefix", which is
unpleasant.

Maybe the selection for the old connection could be performed in several
steps, including the longest prefix:

M-x tramp-rename-all-buffer-files
Enter old Tramp connection: /method:badhost:

This connection is proposed, based on current-buffer and/or available
remote connections. You can edit this, or type TAB. TAB results in path
completion, like

Enter old Tramp connection: /method:badhost:/longest/prefix/common/to/all/files

Of course, the implementation for the completion of the longest prefix
must be written newly as well, because the existing completion functions
won't work (badhost is not reachable anymore).

>> Then, Tramp would go through all buffers finding related ones
>> (buffer-file-name must start with "/method:badhost:"). For every such a
>> buffer, it asks interactively
>> 
>> Write file: /method:newhost:/path/to/file
>> 
>> given, that buffer has as buffer-file-name
>> "/method:badhost:/path/to/file". The user can edit the filename, and
>> write to another "/path/to/anotherfile" on newhost, or even change the
>> remote part. Or the user confirms.
>> 
>> Whewther "/method:badhost:" or "/method:newhost:" contains multi-hops,
>> doesn't matter.
>> 
>> We could even take the upper parts of the localname into account:
>> 
>> M-x tramp-rename-all-buffer-files
>> Enter old Tramp connection: /method:badhost:/path/to
>> Enter new Tramp connection: /method:newhost:/somewhere/else
>
> This is I think a good interface, especially when you start with the
> longest prefix common to all files with the same host-path.

Yep.

>> The file "/method:badhost:/path/to/file" would be written to
>> "/method:newhost:/somewhere/else/file" (still editable).
>> 
>> And finally, the target must not be a remote file name:
>> 
>> M-x tramp-rename-all-buffer-files
>> Enter old Tramp connection: /method:badhost:/path/to
>> Enter new Tramp connection: /somewhere/else
>
> I think it would be more targeted and easier for the user to
> understand if it’s a `tramp-rename-host-files` or so.  I.e. it renames
> only those tramp buffers visiting the same hostpath.  Then the
> function can prompt with the host path + shortest common prefix
> (e.g. /method:badhosts:/shortest/local/prefix), and allow the user to
> change it (e.g., to /method:hophost|method:newhost:/newpath/prefix).

`tramp-rename-host-files' does not fit. The remote part distinguishes
not only by host names, but also method and user names. What about
`tramp-rename-remote-files'?

>> would write "/method:badhost:/path/to/file" to "/somewhere/else/file".
>> 
>> After handling all such buffers, the command would cleanup the
>> connection to "/method:badhost:".
>> 
>> Something like this …
>
> Sounds like a great start, thanks for throwing some energy at it so quickly.  

Well, I have the feeling for a while that we need this kind of
functionality. Your message was the final kick for me to work on it.

> JD

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]