> On Nov 14, 2019, at 8:01 AM, Michael Albinus <[email protected]> wrote: > > JD Smith <[email protected] <mailto:[email protected]>> writes: > > >> * 2nd Prompt: >> >> * 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?) > 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. >> * So in my opinion, interactive calling of set-visited-file-name seems >> like an unnecessary and confusing duplication. If I wanted to >> change the file *name* itself, I could first change the host and >> directory using tramp-rename-these-files, then C-x w it easily >> enough. I can’t think of a changing network scenario which would >> require the *filename* to change. It seems to me just >> (set-visited-file-name buffer-file-name) should suffice for all >> reasonable scenarios. >> * Then no-confirm can apply to just one thing: the >> default-rename-alist. Right now there is no prefix or no-confirm >> based method to call change-these-files that avoids the unnecessary >> final `set-visited-file-name` prompt. > > Well, maybe we need another user option in order to distinguish the two > confirmation cases. `tramp-confirm-rename-file-names', if set to t (the > default), triggers the confirmation of `set-visited-file-name'. A value > of nil doesn't ask for. The NO-CONFIRM argument is not needed anymore, > we just use the prefix argument of the command to avoid confirmation of > the target path. That could work. NO-CONFIRM does double duty as well with the alist. 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. > I've implemented this; you might play with. I’ll have a look. > >> 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). > >> 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. > >> 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. Best, JD
