> On Nov 10, 2019, at 10:12 AM, Michael Albinus <[email protected]> wrote:
>
> Michael Albinus <[email protected]> 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
