> On Nov 11, 2019, at 7:55 AM, Michael Albinus <michael.albi...@gmx.de> wrote:
>
> JD Smith <jdtsm...@gmail.com> 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.