> On Nov 4, 2019, at 3:34 AM, Michael Albinus <[email protected]> wrote: > > JD Smith <[email protected] <mailto:[email protected]>> writes: > > Hi, > > [pls keep [email protected] <mailto:[email protected]> in Cc. I'd > appreciate comments also from > other users] > >>> Well, I'm still playing with scenarios. For the time being, I have >>> called the function `tramp-rename-all-buffer-files' (but I'm not fixed >>> on this name). The idea is to rename a prefix by another prefix for >>> buffer-file-name in all related buffers, and let the user confirm that >>> choice for every matching buffer. The interactive case would be >>> >>> M-x tramp-rename-all-buffer-files >>> Enter old Tramp connection: /method:badhost: >>> Enter new Tramp connection: /method:newhost: >> >> You could consider prompting with the longest prefix common to all >> files being visited on badhost. > > But badhost is just a guess, based on a possible current-buffer with a > remote default-directory. If the current-buffer isn't remote, the > initial value must be chosen from the different remote connections which > exist. There can be several ones.
I was imagining running the command in a non-tramp buffer would result in an error. > And if it is the wrong guess, you need to edit the proposed initial > value. So you would also need to remove the "longest prefix", which is > unpleasant. But now that I think of it, if you are visiting files at 10 different hosts, and *all* now need to be redirected through a new hop (for example), you might in fact prefer to rename all at once. > Maybe the selection for the old connection could be performed in several > steps, including the longest prefix: > > M-x tramp-rename-all-buffer-files > Enter old Tramp connection: /method:badhost: > > This connection is proposed, based on current-buffer and/or available > remote connections. You can edit this, or type TAB. TAB results in path > completion, like > > Enter old Tramp connection: > /method:badhost:/longest/prefix/common/to/all/files > > Of course, the implementation for the completion of the longest prefix > must be written newly as well, because the existing completion functions > won't work (badhost is not reachable anymore). This is really important. Ido and other aggressive completion tools seem to be good at hanging tramp when a host is no longer reachable. Since presumably the new command will be used when the host is no longer contactable, completion that visits the bad host has to be avoided. Of course, completion of the new host would work fine (assuming it’s valid). >>> Then, Tramp would go through all buffers finding related ones >>> (buffer-file-name must start with "/method:badhost:"). For every such a >>> buffer, it asks interactively >>> >>> Write file: /method:newhost:/path/to/file >>> >>> given, that buffer has as buffer-file-name >>> "/method:badhost:/path/to/file". The user can edit the filename, and >>> write to another "/path/to/anotherfile" on newhost, or even change the >>> remote part. Or the user confirms. >>> >>> Whewther "/method:badhost:" or "/method:newhost:" contains multi-hops, >>> doesn't matter. >>> >>> We could even take the upper parts of the localname into account: >>> >>> M-x tramp-rename-all-buffer-files >>> Enter old Tramp connection: /method:badhost:/path/to >>> Enter new Tramp connection: /method:newhost:/somewhere/else >> >> This is I think a good interface, especially when you start with the >> longest prefix common to all files with the same host-path. > > Yep. > >>> The file "/method:badhost:/path/to/file" would be written to >>> "/method:newhost:/somewhere/else/file" (still editable). >>> >>> And finally, the target must not be a remote file name: >>> >>> M-x tramp-rename-all-buffer-files >>> Enter old Tramp connection: /method:badhost:/path/to >>> Enter new Tramp connection: /somewhere/else >> >> I think it would be more targeted and easier for the user to >> understand if it’s a `tramp-rename-host-files` or so. I.e. it renames >> only those tramp buffers visiting the same hostpath. Then the >> function can prompt with the host path + shortest common prefix >> (e.g. /method:badhosts:/shortest/local/prefix), and allow the user to >> change it (e.g., to /method:hophost|method:newhost:/newpath/prefix). > > `tramp-rename-host-files' does not fit. The remote part distinguishes > not only by host names, but also method and user names. What about > `tramp-rename-remote-files'? That’s good. Though maybe confusing if people imagine it would rename the file locally on disk? Perhaps `tramp-edit-host-filepaths`? That name also gives me the idea for an alternative interface (picking up on your multiple steps approach): Find all unique `/method1:host|method2:hop1…` values across all tramp buffers `tramp-edit-host-files` would invoke a two stage input: Prompt 1: Choose host to edit (empty for all hosts, use completion with unique list from #1) Prompt 2: /method:host|method2:hop1…:/longest/prefix/path. Edit this to replace the longest prefix path and hostname, etc. If empty (all hosts): Repeat Prompt 2 for all hosts in the unique list above. If not empty (particular host): Present 2nd prompt only for that host tramp-cleanup all edited buffers. This would even let you change just method all at once. >>> would write "/method:badhost:/path/to/file" to "/somewhere/else/file". >>> >>> After handling all such buffers, the command would cleanup the >>> connection to "/method:badhost:". >>> >>> Something like this … >> >> Sounds like a great start, thanks for throwing some energy at it so quickly. >> > > Well, I have the feeling for a while that we need this kind of > functionality. Your message was the final kick for me to work on it. Great. BTW, I see that tramp has a newer version on ELPA, but this does not show via `package-list-packages`. Is tramp being officially distributed as an ELPA package now? Best, JD
