> On Nov 10, 2019, at 12:36 PM, Michael Albinus <[email protected]> wrote: > > JD Smith <[email protected] <mailto:[email protected]>> writes: > > Hi, > >>>>> - Now, the command goes through all buffers. Buffers which have a >>>>> buffer-file-name starting with the old name, "/ssh:bad:/tmp/", >>>>> are >>>>> presented to me, plus the prompt "Set visited file name: >>>>> /ssh:good:/var/tmp/". Confirming this with RET, sets the new >>>>> name. This is editable, of course. >>>>> >>>>> Also confused here. Is this not a new file but a *new* path to file? >>>>> I entered “file.txt” here, which was interpreted as a directory, >>>>> leading to auto-save errors for directory “file.txt/“. If it is a >>>>> new file *path*, it seems redundant with the search-replace of the >>>>> longest common prefix string. >>>> >>>> Here I am undecided how to handle best. We have two options, call either >>>> `set-visited-file-name', or `write-file'. The former just changes the >>>> buffer's file name and marks the buffer as modified. The latter writes >>>> the buffer contents to the new location. >> >> I like the mark as modified version you’ve used. That way you can >> change your mind if you did it incorrectly. But here I was referring >> to renaming the local file directory vs. the filename itself. > > But there is no problem, at least in my test. If I choose SOURCE > "/ssh:bad:/tmp" and TARGET "/ssh:good:/var/tmp" and the command loops > through related buffers, it always asks me > > Set visited file name: /ssh:good:/var/tmp/ > > If I confirm with RET, the file will be saved under the same basic name > as it is on host bad. If I complete the file name to, say, > /ssh:good:/var/tmp/file.txt and confirm then with RET, it is saved under > this name. > > All tested with "emacs -Q", which is the primary test case. Could it be > that ido chimes in your test? > >>>> I've decided for the first option, because it let you decide later, >>>> whether you need to save this file really, or whether it is not >>>> important enough to be saved somewhere else. >>>> >>>> I understand that the default UI of interactive `set-visited-file-name' >>>> is not convenient here. I will see whether I could write a wrapper >>>> around. At least, it calls for proper documentation. >> >> Yeah for my usage case the simplest interface would be just-one-prompt: >> >> Change the remote filepath to: /method:badhost:/longest/common >> >> and then just edit the prompted text as needed, often just >> "/method:hophost|method:badhost:/longest/common”. > > There is a problem how remote file names are completed (again, with ido > it might be different). If you have a file name like "/method:badhost:" > or "/method:hophost|method:badhost:" you could always type something in > the host name part and complete with TAB. As long as you have *no* local > file name, just host name completion is applied, so you could edit > "badhost" and use as many TABs as you want. > > As soon there is just one character for the local file name, Tramp > assumes the host name is perfect, and it connects to this (partial) host > name in order to complete the local file name. This is good for errors. > > Try it yourself ...
I have certainly noticed the “host is perfect” assumption and resulting errors. I’m not sure how completion enters into my suggestion of a shorter, single-prompt interface, which should work with or without completion? But I guess I could see trying to complete the /method:host when there is some local filename would be frustrating. Maybe that means my below suggestion of method-host only renaming makes sense for the single prompt version. >> To simplify even further, having a version called >> `tramp-rename-this-remote` which doesn’t even include any local >> filepath common prefix would also be convenient and less error-prone. > > But you have it already. If your current buffer is visiting a file on > badhost, you might do the following: > > M-x tramp-rename-remote-files > Enter old Tramp connection: /ssh:bad: RET > Enter new Tramp connection: /ssh: ;; complete with "new" to > Enter new Tramp connection: /ssh:new: RET > Set visited file name: /ssh:new:/tmp RET > > Oops, there's still an error, the last prompt doesn't ask for > "/ssh:new:/tmp" but "/ssh:new:/". Will fix it, and then it behaves as > you expect, right? Yes except that was *three* prompts. What would be ideal (for this simple case) is *just one prompt*: M-x tramp-rename-this-remote Change Remote Tramp Connection: /ssh:bad: (edit in place to /ssh:new:, RET) Remote for all buffers visiting /ssh:bad are immediately changed, and marked as edited. >>> I've reworked the docstring, and I've added also some phrases to the >>> Info manual. Since I'm notorious bad in writing proper documentation, >>> feedback is much appreciated! >> >> Probably best to finalize the interface first, then I’m happy to take >> a look at the docs. > > Sure. But I just wanted to mention it, so you are prepared. :)
