> On Nov 14, 2019, at 9:19 AM, Michael Albinus <michael.albi...@gmx.de> wrote: > > JD Smith <jdtsm...@gmail.com <mailto:jdtsm...@gmail.com>> writes: > > Hi, > >> * What I don’t understand here is why, after the 1st prompt of >> rename-these-files, I get a 2nd prompt “Set visited file name” >> at all. Should that not have already been taken care of by >> the 1st prompt, which included the longest common prefix for >> all files on method:host? I.e. if I didn’t change the local >> file directory in the 1st prompt, why would I be asked again >> with a 2nd prompt if I want to? >> >> There could be several buffers with a buffer-file-name matching >> the renaming. Some of them might have been forgotten by the user. >> Therefore, in order not to get surprises, the renaming shall be >> confirmed by the user, as default. If this is not intended, we >> have NO-CONFIRM. >> >> NO-CONFIRM doesn’t work for `rename-these-files`, since it is then >> just passed on to `rename-files`, because no prompt is made, so target >> is nil. I still find this confusing. I imagine many will presume >> tramp is asking them to enter a new filename at this point. Maybe >> just a y-or-n would be better (rename this buffer? How about this one? >> And this other one you forgot about?) > > Have you played with the new code? NO-CONFIRM does not exist any longer > as argument. Just the command's prefix arg is taken for decision, > whether you'll need to specify TARGET, or not. > > I hope, the new interface answers some of your questions ...
Thanks, tried this in the new version. C-u M-x tramp-reload-these-files simply complains about no target and aborts. I’m happy to specify target (since unless I’ve pre-decided on a target via the alist, that’s definitely necessary). I just don’t want to set-visited-file-name them all. See below for (too much) more discussion on this point. >> Furthermore, I plan to implement a local quit. That is, if >> `set-visited-file-name' offers you a change, and you don't want to >> apply it, you hit `C-g', and the renaming of *this* buffer's file >> name is cancelled. The next renaming will be offered, then. >> >> A y-or-no would handle this nicely. > > But then you have to confirm twice: > > * 'y' for "I want to see and edit the file name" > > * the file name itself. > > 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. To make this confusion concrete, here’s the actual workflow I get (for say 5 buffers on a single oldhost): Visiting File /ssh:oldhost:/path/to/file1 [M-x tramp-rename-these-files] “Change Tramp connection `/ssh:oldhost:/path/to/‘: /ssh/oldhost/:/path/to” (with point at the ‘/:’). OK good, this should work. Let me just... Edit this to be "/ssh:newhost:/path/to/“ (removing the superfluous ‘/‘ before the final colon) [Ret] “Set Visited file name: /ssh:newhost:/path/to/“. Hmmm, what is this? The filename is empty. Am I supposed to put a file name in? For which file? Maybe just hit return? Not clear. So let’s try return. [Ret] “Set Visited file name: /ssh:newhost:/path/to/“. I already answered that. Why is it asking me the same questions again? Did my buffer in the small top left window change? I wasn’t watching I was reading the mini buffer. Maybe my keyboard malfunctioned. I’ll try that again... [Ret] “Set Visited file name: /ssh:newhost:/path/to/“ OK I definitely hit return. This thing is really is a broken record. Maybe I should just cancel this whole thing... [C-g] “Set Visited file name: /ssh:newhost:/path/to/“ OMG, it broke C-g. I’ll never escape. Despair. 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. 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 :). >> It seems the interactive version of set-visited-file-name is not >> really the confirmation you are seeking. You don’t intend the user to >> edit the renamed filepath during set-visited-file-name, just hit >> return to accept it. So perhaps a simple y-or-no would be more >> appropriate. > > Yes, I offer both: RET to accept, or <edit> RET to change. An additional > y-or-n would be superfluous, I believe. > >> I've implemented this; you might play with. >> >> I’ll have a look. > > Pls. I'm interested in your feedback for what I've changed :-) Sorry that I seem stuck on this 2nd prompt business. One real problem here is that “RET to accept” is by no means obvious, since it’s not clear what’s being asked for, and why. Probably hard to change set-visited-file-name’s prompt text…. >> The first matching item specifies the target to be applied for >> renaming buffer file names from source via tramp-rename-files. >> source is a regular expressions, which matches a remote file >> name. target must be a directory name, which could be remote. >> >> Why must target be a directory name, can it not be *just* a >> user@method:host path? I.e. what would be wrong with an alist >> entry >> like: >> >> ‘((“/ssh:oldhost” . “/ssh:hophost|ssh:oldhost”)) >> >> Add a trailing colon ":", and you have a directory name. >> >> That’s not what most users will think of as a “directory" name (i.e. >> which would require something after the colon). > > But it is! If you dislike it, use "/ssh:method:host:/" Fair enough. I guess most would imagine “the host part” and “the directory part” to be separated by the final colon. But this is just semantics. >> In fact from your examples it seems this should be possible >> (btw, love the %u & %h with a regex: very powerful!). Also, >> is the final colon required on host-method only renames? >> >> This I don't understand. >> >> 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 do note that if you mess up a rename, accidentally using an >> unreachable hostname, Emacs freezes with “Waiting for prompts >> from remote shell…”, and sometimes doesn’t time out. This >> isn’t actually new behavior, just somewhat easy to trigger >> using these bulk renames. Often no amount of C-g’ing stops >> it, and you must kill Emacs (possibly with a USR2 signal, >> which recovers it). This likely has nothing to do with >> renaming. It probably has a lot to do with my need for the >> rename functionality you’ve added. >> >> Yes. This is a long standing problem, to avoid Tramp blocking >> whole Emacs. I haven't a general solution yet, because it does not >> depend only on Tramp. >> >> Last year, I've started to bring asynchronous file operations to >> Tramp. But this work is stalled, due to problems with threads in >> Emacs. >> >> I wondered if some of the new async features would be helpful. Let me >> know if you need someone to test. > > Thanks for the offer. However, it's not a problem of testing. The > problem is inherent in the thread implementation of Emacs. When you have > two threads running in parallel, and bot query something from the > minibuffer, you cannot distinguish what comes from where. This has been > discussed in length on the emacs-devel mailing list, with no > solution. And so my work ist stalled :-( Aha, that’s too bad. Honestly I would be happy enough if it would just time out in a reliable way (<10sec or so). Now sometime it times-out, sometimes it hangs “forever”. Especially in the “bad host” context. Hanging a separate thread forever would probably be preferable (especially since the main thread could presumably kill the others!). Good luck getting this implemented. And thanks very much for your patience with all this nuance. JD
