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: JD Smith
Subject: Re: No longer accessible host paths
Date: Fri, 8 Nov 2019 14:26:56 -0500

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 <address@hidden> wrote:

Michael Albinus <address@hidden> 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 via email to

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