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'. > 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. > 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. > 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? > JD Best regards, Michael.
