> On Nov 15, 2019, at 7:54 AM, Michael Albinus <[email protected]> wrote:
>
> JD Smith <[email protected]> writes:
>
> Hi,
>
>> Thanks, tried this in the new version. C-u M-x
>> tramp-reload-these-files simply complains about no target and aborts.
>
> I guess you have called `tramp-rename-these-files' on a local buffer, yes?
> It is a user-error. And this is intended: `tramp-rename-these-files'
> works only if you are visiting a remote buffer. Otherwise, you shall
> call `tramp-rename-files'.
>
> This is our old discussion about having one command, or two. I've
> extended the error message, advising `tramp-rename-files'.
No, this is in a remote tramp buffer. Steps to reproduce:
Load a tramp buffer, which is not specified in the default-rename-alist.
C-u M-x tramp-rename-these-files
Error: “There is no target specified”
It’s possible I’ve misinterpreted the point of the prefix, but it’s now quite
irrelevant given your prompt 2 interface updates (see below).
>> I understand that your use case doen't expect to change the file
>> name. But other people might have different preferences, and I
>> want to be prepared.
>>
>> I mean _substitute_ a y-or-n for the prompt. I tried the C-g method
>> (which is like selecting “no”), and that works, leaving some buffers
>> behind on an ala carte basis.
>>
>> But I still maintain a random prompt saying "Set Visited File:
>> /method:host:/common/path" is going to be *very* confusing to people.
>> It still confuses me honestly. To understand what you are being asked
>> (and why), you have to notice that the current buffer changed (if it
>> did), and you may have many windows which means only one of them
>> changed. And the prompt doesn’t mention at all *which* file you are
>> setting the visited filename for, only the new host and directory path
>> *which is the same for all files being changed* (for a reload-these
>> anyway). So you have to somehow infer that by looking for a window
>> with a potential active remote-file-visiting buffer.
>
> Understood. I have rewritten the 2nd prompt machinery to give you a
> yes/no/all/none/edit choice (shamelessly stolen from ´dired-query').
>
>> And here’s the workflow I wish I had:
>>
>> * Visiting File [/ssh:oldhost:/path/to/]
>> * M-x tramp-rename-these-files,
>> * “Change Tramp connection in 5 buffers `/ssh:oldhost:/path/to/‘:
>> /ssh/oldhost:/path/to”
>> * edit this to be "/ssh:newhost:/path/another/“ [Ret] (no window
>> buffers change…)
>> * Message: “Tramp connection changed in 5 buffers to
>> /ssh:newhost:/path/to/"
>>
>> All of the complexity to me comes because the current command tries to
>> overload two very different actions: 1) change method/host/common
>> directory path and 2) change the actual filename. The latter isn’t
>> really related to the thrust of this command, in my opinion. What
>> filename changes would be precipitated by a changing network
>> circumstance? And if you want to rename the file (not alter its
>> method/host/directory path), you can simply C-x C-w after fixing up
>> the host & directory paths.
>
> Before I explain in length: could you pls try the new code? I hope it is
> self-explanary.
Thanks, this is very *very* much improved! I can hit “!” to “do everything I
said”, skip any file selectively, edit, or abort any rename. And yes, even
change the filename itself if I wanted to for some reason. This satisfies
everything we both want I think.
One small quibble is that “q” is not really “do not change any of the buffers”
but “do not change any further buffers”. I.e. if you already said “y”, those
earlier buffers in the list remain renamed. It might be preferable to revert
those original changes with a “q”, as in “never mind I want to abort this whole
renaming thing”.
>> Anyway, if you disagree entirely about this I’ll drop it, I just know
>> in 2 weeks when I need to reach for this command, I’ll still be
>> baffled by that 2nd prompt :).
>
> NoNoNo !!!
>
> I'm the developer, and usually I know what I'm written, and what to
> enter in the minibuffer prompt. Therefore, I don't count for final
> decision on UI.
>
> I'm very depending on your (and other people) feedback about usefulness.
It’s far improved and definitely more discoverable for occasional users (which
will presumably dominate the user pool) at this point.
>> I think of a directory name requirement as
>> /method:host:/you/need/something/here. But /method:host:
>> works for either. I’m asking should /method:host also work
>> for source and/or target? Possibly not since it’s not yet a
>> confirmed host.
>>
>> You see me still inquiring. Use "/method:host:" instead, and if
>> you dislike default expansion, use "/method:host:/". I don't see
>> how it limits you.
>>
>> Not a limitation just a confusion. Maybe a gentle reminder in the
>> docs here that a path with nothing past the final colon constitutes a
>> default directory on the host.
>
> I haven't touched the doc today. Maybe you could provide some phrases,
> how it would read better?
@code{target} must be a directory name, which could be remote (including remote
directories Tramp infers by default, such as /method:host:)
The only thing I have left to sort out is that Ido is truly terrible with this.
C-f is the normal “get out of Ido and give me a normal prompt”, but it by
default is only bound to that when you are at the end of the mini buffer text.
So our new method of putting point at the host defeats that. And I think it is
responsible for adding a useless trailing slash (ala /method:host/:) but
perhaps Tramp is doing that. So I always have to fix up something that’s
already a mess, like:
/ssh:user@host/:/home/user/:/home/user/
I can’t even defeat Ido with something like:
(add-to-list 'ido-read-file-name-non-ido 'tramp-rename-files)
(add-to-list 'ido-read-file-name-non-ido 'tramp-rename-these-files)
Because it is so “smart” it notices your predicate is file-directory-p and
offers a special directory-reading interface, not falling back to a normal
read-file-name. I’m not familiar with the non-essential concept; would it work
in rename-these as well?
This is really very usable now.
Thanks again,
JD
