No longer accessible host paths

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

No longer accessible host paths

JD Smith-7

Tramp (2.3.5.26.2) commonly hangs my Emacs session in the following scenario:

  • On an internal network at my work, I visit a file via:
    • /ssh:someinternalpath.foo.bar:file
  • I continue to edit the file after leaving the internal network.
  • Later, on another network (at home, etc.) Tramp can no longer access the file via someinternalpath.foo.bar.  File operations, write attempts, etc. hang as Tramp tries in vain to reach the host via a no longer reachable hostname/path. 
  • The various `tramp-cleanup-*` commands do nothing for this problem, since they assume the host is still reachable via the original hostname, and merely reset the cached information. 
  • I can at this point kill the buffer (or Emacs, if hung), and visit the file using
    • /ssh:hopserver.bar.baz|ssh:someinternalpath.foo.bar:file
  • but there is no way to save or write the changes in my local buffer.  So this often hangs Emacs and loses the changes.

Is there some what to effect a `tramp-reset-host` so that a buffer will be marked as no longer visiting any file, and will re-prompt you for a filename so you can write your changes?  Or perhaps a `tramp-change-hostpath` so you can re-enter the (possibly multi-hop) host path to the file?  

If not, this would be a great feature for those who work with networks that have different hostpaths from inside and outside the network. It would also be ideal if an unreachable host timed out and gave you the option to reset or re-enter the host path as well.  

Thanks for Tramp.  I use it daily (and usually love it!).  
Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
JD Smith <[hidden email]> writes:

Hi,

> Tramp (2.3.5.26.2) commonly hangs my Emacs session in the following
> scenario:
>
> * On an internal network at my work, I visit a file via:
>
> * /ssh:someinternalpath.foo.bar:file
>
> * I continue to edit the file after leaving the internal network.
> * Later, on another network (at home, etc.) Tramp can no longer access
>   the file via someinternalpath.foo.bar.  File operations, write
>   attempts, etc. hang as Tramp tries in vain to reach the host via a
>   no longer reachable hostname/path.
> * The various `tramp-cleanup-*` commands do nothing for this problem,
>   since they assume the host is still reachable via the original
>   hostname, and merely reset the cached information.
> * I can at this point kill the buffer (or Emacs, if hung), and visit
>   the file using
>
> * /ssh:hopserver.bar.baz|ssh:someinternalpath.foo.bar:file
>
> * but there is no way to save or write the changes in my local buffer.
>    So this often hangs Emacs and loses the changes.

So why doesn't work

M-x tramp-cleanup-all-connections
C-x w ;; in a remote buffer

The second command, write-file, should ask you for a new file name. This
includes editing the host name.

> Is there some what to effect a `tramp-reset-host` so that a buffer
> will be marked as no longer visiting any file, and will re-prompt you
> for a filename so you can write your changes?

No, such a command does not exist. There is the danger that if you have
a modified buffer, and you remove the buffer-file-name, this buffer is
not covered by auto-save, nor by "C-x s" (save-some-buffers), nor by
"C-x C-c" (save-buffers-kill-terminal). I, for example, count on this
behavior, because I'm notorious in *not* saving buffers.

> Or perhaps a `tramp-change-hostpath` so you can re-enter the (possibly
> multi-hop) host path to the file?

That's a good idea. Will see how to implement it. It shall be a bulk
renaming, for all buffers related to the respective host.

The bulk renaming shall be only for the remote part of a file name,
including existing multi-hops. For the local part, we cannot assume that
a file is located at the very same location on the other host. So Emacs
must go through all related buffers, and offer to edit the new file
name, with the default "/method:newhost:/same/path/to/file".

WDYT?

> If not, this would be a great feature for those who work with networks
> that have different hostpaths from inside and outside the network. It
> would also be ideal if an unreachable host timed out and gave you the
> option to reset or re-enter the host path as well.
>
> Thanks for Tramp.  I use it daily (and usually love it!).

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

JD Smith-7

On Nov 3, 2019, at 5:36 AM, Michael Albinus <[hidden email]> wrote:

JD Smith <[hidden email]> writes:

Hi,

Tramp (2.3.5.26.2) commonly hangs my Emacs session in the following
scenario:

* On an internal network at my work, I visit a file via:

* /ssh:someinternalpath.foo.bar:file

* I continue to edit the file after leaving the internal network.
* Later, on another network (at home, etc.) Tramp can no longer access
 the file via someinternalpath.foo.bar.  File operations, write
 attempts, etc. hang as Tramp tries in vain to reach the host via a
 no longer reachable hostname/path.
* The various `tramp-cleanup-*` commands do nothing for this problem,
 since they assume the host is still reachable via the original
 hostname, and merely reset the cached information.
* I can at this point kill the buffer (or Emacs, if hung), and visit
 the file using

* /ssh:hopserver.bar.baz|ssh:someinternalpath.foo.bar:file

* but there is no way to save or write the changes in my local buffer.
  So this often hangs Emacs and loses the changes.

So why doesn't work

M-x tramp-cleanup-all-connections
C-x w ;; in a remote buffer

The second command, write-file, should ask you for a new file name. This
includes editing the host name.

Because even after cleanup, C-x w hangs Tramp irrecoverably. It could be this relates to my use of ido-write-file, which may probe the host for filename info. In the future I’ll try M-x write-file followed by C-g C-f to disable ido’s file completion niceties and see if I can recover.  Often however nothing will unfreeze Emacs after this hang occurs (even a pkill -USR2 Emacs). 

Is there some what to effect a `tramp-reset-host` so that a buffer
will be marked as no longer visiting any file, and will re-prompt you
for a filename so you can write your changes?

No, such a command does not exist. There is the danger that if you have
a modified buffer, and you remove the buffer-file-name, this buffer is
not covered by auto-save, nor by "C-x s" (save-some-buffers), nor by
"C-x C-c" (save-buffers-kill-terminal). I, for example, count on this
behavior, because I'm notorious in *not* saving buffers.

I certainly see that such a “detached” modified buffer could be dangerous.  Though having unsaved changes that can’t be written without hanging Emacs is also quite problematic.  Some of this may be an unfortunate interaction between ido and Tramp. 

Or perhaps a `tramp-change-hostpath` so you can re-enter the (possibly
multi-hop) host path to the file?

That's a good idea. Will see how to implement it. It shall be a bulk
renaming, for all buffers related to the respective host.

The bulk renaming shall be only for the remote part of a file name,
including existing multi-hops. For the local part, we cannot assume that
a file is located at the very same location on the other host. So Emacs
must go through all related buffers, and offer to edit the new file
name, with the default "/method:newhost:/same/path/to/file".

WDYT?

I think that would work well, especially for the common case of visiting multiple files on the now inaccessible host.  I wonder if it would it be possible to first test if the local path on newhost remains valid and reuse it, rather than just prompting to edit localpath in all related buffers?  Perhaps a buffer local `possible-new-host` var?  Then, on any file access, try it.  If it succeeds, update the buffer filename and clear possible-new-host. If it fails, prompt the user for another local filename.  

I guess the concern there could be that localpath is writeable, but still wrong, and Tramp wouldn’t know.   So alternatively, perhaps the bulk rename could apply to the remote part and any matching stem prefix of the local part, e.g. if I’m visiting two files:

/method:badhost:/path/to/a.txt
/method:badhost:/path/from/b.txt

I could M-x tramp-bulk-rename-hostpath 

from: /method:badhost:/path 
to: /method:hophost|method:goodhost:/other/path

If you do this incorrectly, you could have unwritable filepaths, but that’s the situation you were already in, so you are no worse off!

Thanks for considering.

Best,

JD

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
JD Smith <[hidden email]> writes:

Hi,

>     Or perhaps a `tramp-change-hostpath` so you can re-enter the
>     (possibly multi-hop) host path to the file?
>
>     That's a good idea. Will see how to implement it. It shall be a
>     bulk renaming, for all buffers related to the respective host.
>
>     The bulk renaming shall be only for the remote part of a file
>     name, including existing multi-hops. For the local part, we cannot
>     assume that a file is located at the very same location on the
>     other host. So Emacs must go through all related buffers, and
>     offer to edit the new file name, with the default
>     "/method:newhost:/same/path/to/file".
>
>     WDYT?
>
> I think that would work well, especially for the common case of
> visiting multiple files on the now inaccessible host.  I wonder if it
> would it be possible to first test if the local path on newhost
> remains valid and reuse it, rather than just prompting to edit
> localpath in all related buffers?  Perhaps a buffer local
> `possible-new-host` var?  Then, on any file access, try it.  If it
> succeeds, update the buffer filename and clear possible-new-host. If
> it fails, prompt the user for another local filename.  
>
> I guess the concern there could be that localpath is writeable, but
> still wrong, and Tramp wouldn’t know.   So alternatively, perhaps the
> bulk rename could apply to the remote part and any matching stem
> prefix of the local part, e.g. if I’m visiting two files:
>
> /method:badhost:/path/to/a.txt
> /method:badhost:/path/from/b.txt
>
> I could M-x tramp-bulk-rename-hostpath
>
> from: /method:badhost:/path
> to: /method:hophost|method:goodhost:/other/path
>
> If you do this incorrectly, you could have unwritable filepaths, but
> that’s the situation you were already in, so you are no worse off!

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:

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

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

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

> Thanks for considering.
>
> Best,
>
> JD

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
JD Smith <[hidden email]> writes:

Hi,

[pls keep [hidden email] 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 | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

JD Smith-7


On Nov 4, 2019, at 3:34 AM, Michael Albinus <[hidden email]> wrote:

JD Smith <[hidden email]> writes:

Hi,

[pls keep [hidden email] 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.

I was imagining running the command in a non-tramp buffer would result in an error.  

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.

But now that I think of it, if you are visiting files at 10 different hosts, and *all* now need to be redirected through a new hop (for example), you might in fact prefer to rename all at once.  

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

This is really important.  Ido and other aggressive completion tools seem to be good at hanging tramp when a host is no longer reachable. Since presumably the new command will be used when the host is no longer contactable, completion that visits the bad host has to be avoided. Of course, completion of the new host would work fine (assuming it’s valid). 

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

That’s good.  Though maybe confusing if people imagine it would rename the file locally on disk?  Perhaps `tramp-edit-host-filepaths`?  

That name also gives me the idea for an alternative interface (picking up on your multiple steps approach):

  • Find all unique `/method1:host|method2:hop1…` values across all tramp buffers
  • `tramp-edit-host-files` would invoke a two stage input:
    1. Prompt 1: Choose host to edit (empty for all hosts, use completion with unique list from #1)
    2. Prompt 2: /method:host|method2:hop1…:/longest/prefix/path.  Edit this to replace the longest prefix path and hostname, etc.
  • If empty (all hosts): Repeat Prompt 2 for all hosts in the unique list above.
  • If not empty (particular host): Present 2nd prompt only for that host
  • tramp-cleanup all edited buffers.

This would even let you change just method all at once.

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.

Great.  BTW, I see that tramp has a newer version on ELPA, but this does not show via `package-list-packages`.  Is tramp being officially distributed as an ELPA package now?

Best,

JD

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

yary-2
In reply to this post by JD Smith-7
I often have similar scenario of editing via TRAMP and then switching networks, without those issues. I don't use ido, and I do have auto-save to local /tmp for all my tramp buffers, setting "Auto Save File Name Transforms" regexp - see https://www.gnu.org/software/emacs/manual/html_node/tramp/Auto_002dsave-and-Backup.html
Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
yary <[hidden email]> writes:

Hi yari,

> I often have similar scenario of editing via TRAMP and then switching
> networks, without those issues. I don't use ido, and I do have
> auto-save to local /tmp for all my tramp buffers, setting "Auto Save
> File Name Transforms" regexp - see
> https://www.gnu.org/software/emacs/manual/html_node/tramp/Auto_002dsave-and-Backup.html

Yes, that works. But the case in question here is a different
one. Assume, you have a host (the same host) reachable under different
names and IP addresses, depending in which network you are located. At
work, you are in the company network. At home, you access via VPN.

You want to continue your work on the same file, whereever you
are. After you gave moved your laptop to the other network, you must
tell Tramp the new name of the remote machine. Existing buffers shall be
preserved, and updated accordingly.

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
In reply to this post by JD Smith-7
JD Smith <[hidden email]> writes:

Hi,

>     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.
>
> I was imagining running the command in a non-tramp buffer would result
> in an error.  

No. You can give any existing remote connection as SOURCE. The default
directory of current-buffer might just be used as initial value in the
prompt, if possible.

> But now that I think of it, if you are visiting files at 10 different
> hosts, and *all* now need to be redirected through a new hop (for
> example), you might in fact prefer to rename all at once.  

That's another use case. Let's start with the simple case, rename one
connection to another one. That's tricky enough.

If we want to rename several connections at once, we might introduce
another command, which uses the first command as working horse. I could
even think of using regular expressions as SOURCE.

>     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).
>
> This is really important.  Ido and other aggressive completion tools
> seem to be good at hanging tramp when a host is no longer reachable.
> Since presumably the new command will be used when the host is no
> longer contactable, completion that visits the bad host has to be
> avoided.

Yes. Technically, Tramp must let-bind `non-essential' to t in this
case. This is an established technique, and Tramp uses it already at
other places, in order to calm down eager completion functions.

>     `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'?
>
> That’s good.  Though maybe confusing if people imagine it would rename
> the file locally on disk?  Perhaps `tramp-edit-host-filepaths`?  

I do not want to have "host" in the function name. As said, "host" is
not sufficient to determine another remote connection. You need at least
also method and user.

> That name also gives me the idea for an alternative interface (picking
> up on your multiple steps approach):
>
> * Find all unique `/method1:host|method2:hop1…` values across all
>   tramp buffers
> * `tramp-edit-host-files` would invoke a two stage input:
>
> 1 Prompt 1: Choose host to edit (empty for all hosts, use completion
>   with unique list from #1)
> 2 Prompt 2: /method:host|method2:hop1…:/longest/prefix/path.  Edit
>   this to replace the longest prefix path and hostname, etc.
>
> * If empty (all hosts): Repeat Prompt 2 for all hosts in the unique
>   list above.
> * If not empty (particular host): Present 2nd prompt only for that
>   host
> * tramp-cleanup all edited buffers.
>
> This would even let you change just method all at once.

Let's put it back until we have the basic functionality, renaming one
remote connection to another one. I'm even not certain how this basic
command will work; I'm experimenting.

> Great.  BTW, I see that tramp has a newer version on ELPA, but this
> does not show via `package-list-packages`.  Is tramp being officially
> distributed as an ELPA package now?

Yesm Tramp is distributed via GNU ELPA. I'm putting there a new version
every mont or so; the most recent one is Tramp 2.4.2.4 from last week.

`package-list-packages' shows it twice, the version from GNU ELPA, and
the built-in version from your Emacs. You are invited to install the
version from GNU ELPA, if you don't run Emacs 27.0.50 (the development
version).

I hope to have a first version of tramp-rename-remote-files ready this
week, for playing. I would post a patch here, on top of Tramp 2.4.2.4.

> Best,
>
> JD

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
Michael Albinus <[hidden email]> writes:

Hi,

> I hope to have a first version of tramp-rename-remote-files ready this
> week, for playing. I would post a patch here, on top of Tramp 2.4.2.4.

I have implemented a very first shot, see appended patch. It is pretty
much alpha, it needs more careful testing, and it represents just where
I stand now. Improvements welcome, but stabilization first. Proper
documentation is also missing.

You can apply this patch on top of Tramp 2.4.2.4 from GNU ELPA. I guess
it would work also on top og Tramp 2.3, but I haven't tested yet.

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

- Now, the next TAB gives me the longest common path of all buffers
  connected to /ssh:bad: - this is "/ssh:bad:/tmp/".

- After RET, I get the prompt "Enter new Tramp connection: /ssh:". The
  Tramp method of the old connection is offered as initial completion.

- Via usual minibuffer completion, I have "/ssh:good:/var/tmp/". I
  confirm this with RET

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

Well, that's it. The buffer file names are renamed, the buffers are
marked modified. Now you can save them (or not :-)

Happy testing! Any feedback is more than welcome.

>> Best,
>>
>> JD

Best regards, Michael.


attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

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

(autoload 'tramp-rename-remote-files "tramp-cmds" "\
Replace in all buffers `buffer-file-name's SOURCE by TARGET.
SOURCE is a remote directory name, which could contain also a
localname part.  TARGET is the directory name SOURCE is replaced
with.  Often, TARGET is also a remote file name on another
machine, but it can also be a local file name.

On all buffers, which have a `buffer-file-name' matching SOURCE,
this name is modified by replacing SOURCE with TARGET.  This is
applied by calling `set-visited-file-name'.  The buffers are
marked modified, and must be saved explicitly.

The remote connection identified by SOURCE is flushed by
`tramp-cleanup-connection' unless there still exists buffers with
a `buffer-file-name' pointing to this remote connection, or unless
KEEP-CONNECTION is non-nil.  Interactively, KEEP-CONNECTION is
set to the prefix argument." t nil)

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

On Nov 8, 2019, at 10:01 AM, Michael Albinus <[hidden email]> wrote:

Michael Albinus <[hidden email]> writes:

Hi,

I hope to have a first version of tramp-rename-remote-files ready this
week, for playing. I would post a patch here, on top of Tramp 2.4.2.4.

I have implemented a very first shot, see appended patch. It is pretty
much alpha, it needs more careful testing, and it represents just where
I stand now. Improvements welcome, but stabilization first. Proper
documentation is also missing.

You can apply this patch on top of Tramp 2.4.2.4 from GNU ELPA. I guess
it would work also on top og Tramp 2.3, but I haven't tested yet.

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. 

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

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

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

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

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

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.

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?

JD

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
JD Smith <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
Michael Albinus <[hidden email]> writes:

Hi,

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

Should be fixed now. Pushed to git.

>> JD

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
In reply to this post by Michael Albinus
Michael Albinus <[hidden email]> writes:

Hi,

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

I've reworked the docstring, and I've added also some phrases to the
Info manual. Since I'm notorious bad in writing proper documentation,
feedback is much appreciated!

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

JD Smith-7

> On Nov 10, 2019, at 10:12 AM, Michael Albinus <[hidden email]> wrote:
>
> Michael Albinus <[hidden email]> writes:
>
> Hi,
>
>>>    - 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 like the mark as modified version you’ve used.  That way you can change your mind if you did it incorrectly.  But here I was referring to renaming the local file directory vs. the filename itself.  

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

Yeah for my usage case the simplest interface would be just-one-prompt:

        Change the remote filepath to: /method:badhost:/longest/common

and then just edit the prompted text as needed, often just "/method:hophost|method:badhost:/longest/common”.  To simplify even further, having a version called `tramp-rename-this-remote` which doesn’t even include any local filepath common prefix would also be convenient and less error-prone.

> I've reworked the docstring, and I've added also some phrases to the
> Info manual. Since I'm notorious bad in writing proper documentation,
> feedback is much appreciated!

Probably best to finalize the interface first, then I’m happy to take a look at the docs.

Thanks,

JD


Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
JD Smith <[hidden email]> writes:

Hi,
 

>>>>    - 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 like the mark as modified version you’ve used.  That way you can
> change your mind if you did it incorrectly.  But here I was referring
> to renaming the local file directory vs. the filename itself.

But there is no problem, at least in my test. If I choose SOURCE
"/ssh:bad:/tmp" and TARGET "/ssh:good:/var/tmp" and the command loops
through related buffers, it always asks me

Set visited file name: /ssh:good:/var/tmp/

If I confirm with RET, the file will be saved under the same basic name
as it is on host bad. If I complete the file name to, say,
/ssh:good:/var/tmp/file.txt and confirm then with RET, it is saved under
this name.

All tested with "emacs -Q", which is the primary test case. Could it be
that ido chimes in your test?

>>> 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.
>
> Yeah for my usage case the simplest interface would be just-one-prompt:
>
> Change the remote filepath to: /method:badhost:/longest/common
>
> and then just edit the prompted text as needed, often just
> "/method:hophost|method:badhost:/longest/common”.

There is a problem how remote file names are completed (again, with ido
it might be different). If you have a file name like "/method:badhost:"
or "/method:hophost|method:badhost:" you could always type something in
the host name part and complete with TAB. As long as you have *no* local
file name, just host name completion is applied, so you could edit
"badhost" and use as many TABs as you want.

As soon there is just one character for the local file name, Tramp
assumes the host name is perfect, and it connects to this (partial) host
name in order to complete the local file name. This is good for errors.

Try it yourself ...

> To simplify even further, having a version called
> `tramp-rename-this-remote` which doesn’t even include any local
> filepath common prefix would also be convenient and less error-prone.

But you have it already. If your current buffer is visiting a file on
badhost, you might do the following:

M-x tramp-rename-remote-files
Enter old Tramp connection: /ssh:bad: RET
Enter new Tramp connection: /ssh: ;; complete with "new" to
Enter new Tramp connection: /ssh:new: RET
Set visited file name: /ssh:new:/tmp RET

Oops, there's still an error, the last prompt doesn't ask for
"/ssh:new:/tmp" but "/ssh:new:/". Will fix it, and then it behaves as
you expect, right?

>> I've reworked the docstring, and I've added also some phrases to the
>> Info manual. Since I'm notorious bad in writing proper documentation,
>> feedback is much appreciated!
>
> Probably best to finalize the interface first, then I’m happy to take
> a look at the docs.

Sure. But I just wanted to mention it, so you are prepared.

> Thanks,
>
> JD

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
Michael Albinus <[hidden email]> writes:

Hi,

> But you have it already. If your current buffer is visiting a file on
> badhost, you might do the following:
>
> M-x tramp-rename-remote-files
> Enter old Tramp connection: /ssh:bad:/tmp/ RET
> Enter new Tramp connection: /ssh: ;; complete with "new" to
> Enter new Tramp connection: /ssh:new: RET
> Set visited file name: /ssh:new:/tmp/ RET
>
> Oops, there's still an error, the last prompt doesn't ask for
> "/ssh:new:/tmp/" but "/ssh:new:/". Will fix it, and then it behaves as
> you expect, right?

Should be fixed now.

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

JD Smith-7
In reply to this post by Michael Albinus


On Nov 10, 2019, at 12:36 PM, Michael Albinus <[hidden email]> wrote:

JD Smith <[hidden email]> writes:

Hi,

  - 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 like the mark as modified version you’ve used.  That way you can
change your mind if you did it incorrectly.  But here I was referring
to renaming the local file directory vs. the filename itself.

But there is no problem, at least in my test. If I choose SOURCE
"/ssh:bad:/tmp" and TARGET "/ssh:good:/var/tmp" and the command loops
through related buffers, it always asks me

Set visited file name: /ssh:good:/var/tmp/

If I confirm with RET, the file will be saved under the same basic name
as it is on host bad. If I complete the file name to, say,
/ssh:good:/var/tmp/file.txt and confirm then with RET, it is saved under
this name.

All tested with "emacs -Q", which is the primary test case. Could it be
that ido chimes in your test?

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.

Yeah for my usage case the simplest interface would be just-one-prompt: 

Change the remote filepath to: /method:badhost:/longest/common

and then just edit the prompted text as needed, often just
"/method:hophost|method:badhost:/longest/common”.

There is a problem how remote file names are completed (again, with ido
it might be different). If you have a file name like "/method:badhost:"
or "/method:hophost|method:badhost:" you could always type something in
the host name part and complete with TAB. As long as you have *no* local
file name, just host name completion is applied, so you could edit
"badhost" and use as many TABs as you want.

As soon there is just one character for the local file name, Tramp
assumes the host name is perfect, and it connects to this (partial) host
name in order to complete the local file name. This is good for errors.

Try it yourself ...

I have certainly noticed the “host is perfect” assumption and resulting errors.  I’m not sure how completion enters into my suggestion of a shorter, single-prompt interface, which should work with or without completion?  But I guess I could see trying to complete the /method:host when there is some local filename would be frustrating.  Maybe that means my below suggestion of method-host only renaming makes sense for the single prompt version. 

To simplify even further, having a version called
`tramp-rename-this-remote` which doesn’t even include any local
filepath common prefix would also be convenient and less error-prone.

But you have it already. If your current buffer is visiting a file on
badhost, you might do the following:

M-x tramp-rename-remote-files
Enter old Tramp connection: /ssh:bad: RET
Enter new Tramp connection: /ssh: ;; complete with "new" to
Enter new Tramp connection: /ssh:new: RET
Set visited file name: /ssh:new:/tmp RET

Oops, there's still an error, the last prompt doesn't ask for
"/ssh:new:/tmp" but "/ssh:new:/". Will fix it, and then it behaves as
you expect, right?

Yes except that was *three* prompts.  What would be ideal (for this simple case) is *just one prompt*:

M-x tramp-rename-this-remote
Change Remote Tramp Connection: /ssh:bad: (edit in place to /ssh:new:, RET)

Remote for all buffers visiting /ssh:bad are immediately changed, and marked as edited. 

I've reworked the docstring, and I've added also some phrases to the
Info manual. Since I'm notorious bad in writing proper documentation,
feedback is much appreciated!

Probably best to finalize the interface first, then I’m happy to take
a look at the docs.

Sure. But I just wanted to mention it, so you are prepared.

:)




Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

Michael Albinus
JD Smith <[hidden email]> writes:

Hi,

> I have certainly noticed the “host is perfect” assumption and
> resulting errors.  I’m not sure how completion enters into my
> suggestion of a shorter, single-prompt interface, which should work
> with or without completion?  But I guess I could see trying to
> complete the /method:host when there is some local filename would be
> frustrating.  Maybe that means my below suggestion of method-host only
> renaming makes sense for the single prompt version.

Hmm. I have added a new user option, `tramp-default-rename-alist'.  Here
you can specify your preferences for renaming.  If you always want to
rename files from "/ssh:badhost:/path/to/dir/" to
"/ssh:goodhost:/path/to/another/dir/", add the entry

("/ssh:badhost:/path/to/dir/" . "/ssh:goodhost:/path/to/another/dir/")

See the Tramp manual for other examples. Maybe this helps you?

>     M-x tramp-rename-remote-files
>     Enter old Tramp connection: /ssh:bad: RET
>     Enter new Tramp connection: /ssh: ;; complete with "new" to
>     Enter new Tramp connection: /ssh:new: RET
>     Set visited file name: /ssh:new:/tmp/ RET
>
> Yes except that was *three* prompts.  What would be ideal (for this
> simple case) is *just one prompt*:
>
> M-x tramp-rename-this-remote
> Change Remote Tramp Connection: /ssh:bad: (edit in place to /ssh:new:,
> RET)

That won't be possible. You must say both bad and new host, and confirm
them. So you have at least two prompts.

> Remote for all buffers visiting /ssh:bad are immediately changed, and
> marked as edited.

Maybe we can change the third argument of `tramp-rename-remote-files' to
NO-CONFIRM? In case it is non-nil (via a prefix argument of the
command), the new host is taken from `tramp-default-rename-alist'
without a prompt, and the buffer file names are changed also without a
prompt? Then you would have indeed only one prompt.

And you must live with the consequences, if the defaults are not as you
expect ...

WDYT?

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: No longer accessible host paths

JD Smith-7


> On Nov 11, 2019, at 7:55 AM, Michael Albinus <[hidden email]> wrote:
>
> JD Smith <[hidden email]> writes:
>
> Hi,
>
>> I have certainly noticed the “host is perfect” assumption and
>> resulting errors.  I’m not sure how completion enters into my
>> suggestion of a shorter, single-prompt interface, which should work
>> with or without completion?  But I guess I could see trying to
>> complete the /method:host when there is some local filename would be
>> frustrating.  Maybe that means my below suggestion of method-host only
>> renaming makes sense for the single prompt version.
>
> Hmm. I have added a new user option, `tramp-default-rename-alist'.  Here
> you can specify your preferences for renaming.  If you always want to
> rename files from "/ssh:badhost:/path/to/dir/" to
> "/ssh:goodhost:/path/to/another/dir/", add the entry
>
> ("/ssh:badhost:/path/to/dir/" . "/ssh:goodhost:/path/to/another/dir/")
>
> See the Tramp manual for other examples. Maybe this helps you?

It’s an interesting idea.

>>    M-x tramp-rename-remote-files
>>    Enter old Tramp connection: /ssh:bad: RET
>>    Enter new Tramp connection: /ssh: ;; complete with "new" to
>>    Enter new Tramp connection: /ssh:new: RET
>>    Set visited file name: /ssh:new:/tmp/ RET
>>
>> Yes except that was *three* prompts.  What would be ideal (for this
>> simple case) is *just one prompt*:
>>
>> M-x tramp-rename-this-remote
>> Change Remote Tramp Connection: /ssh:bad: (edit in place to /ssh:new:,
>> RET)
>
> That won't be possible. You must say both bad and new host, and confirm
> them. So you have at least two prompts.

Not so if your first prompt is always the same: the /method:host of the tramp file visited in the current buffer.  We know it’s bad, or else you wouldn’t be trying to change it.  No editing required. So all that’s needed is what you want to change it *to*.  Or am I missing something simple?

>> Remote for all buffers visiting /ssh:bad are immediately changed, and
>> marked as edited.
>
> Maybe we can change the third argument of `tramp-rename-remote-files' to
> NO-CONFIRM? In case it is non-nil (via a prefix argument of the
> command), the new host is taken from `tramp-default-rename-alist'
> without a prompt, and the buffer file names are changed also without a
> prompt? Then you would have indeed only one prompt.
>
> And you must live with the consequences, if the defaults are not as you
> expect ...
>
> WDYT?

I like the idea of quick renames via an alist for people who often find themselves with the same badhost's.

I still believe renaming *this remote* is truly a single prompt operation.  It would signal an error if called in a non-tramp buffer. But otherwise, tramp fully knows the /method:badhost for the currently visited file.  Whether this-remote is a standalone command or prefix-based alteration of the full command is not as important I think as having it in the first place!

Thanks for engaging on this.



12