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