Re: No longer accessible host paths

[Michael Albinus]

JD Smith <address@hidden> 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.