[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: No longer accessible host paths
From: |
Michael Albinus |
Subject: |
Re: No longer accessible host paths |
Date: |
Sun, 03 Nov 2019 15:28:55 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
JD Smith <address@hidden> writes:
Hi,
> Or perhaps a `tramp-change-hostpath` so you can re-enter the
> (possibly multi-hop) host path to the file?
>
> That's a good idea. Will see how to implement it. It shall be a
> bulk renaming, for all buffers related to the respective host.
>
> The bulk renaming shall be only for the remote part of a file
> name, including existing multi-hops. For the local part, we cannot
> assume that a file is located at the very same location on the
> other host. So Emacs must go through all related buffers, and
> offer to edit the new file name, with the default
> "/method:newhost:/same/path/to/file".
>
> WDYT?
>
> I think that would work well, especially for the common case of
> visiting multiple files on the now inaccessible host. I wonder if it
> would it be possible to first test if the local path on newhost
> remains valid and reuse it, rather than just prompting to edit
> localpath in all related buffers? Perhaps a buffer local
> `possible-new-host` var? Then, on any file access, try it. If it
> succeeds, update the buffer filename and clear possible-new-host. If
> it fails, prompt the user for another local filename.
>
> I guess the concern there could be that localpath is writeable, but
> still wrong, and Tramp wouldn’t know. So alternatively, perhaps the
> bulk rename could apply to the remote part and any matching stem
> prefix of the local part, e.g. if I’m visiting two files:
>
> /method:badhost:/path/to/a.txt
> /method:badhost:/path/from/b.txt
>
> I could M-x tramp-bulk-rename-hostpath
>
> from: /method:badhost:/path
> to: /method:hophost|method:goodhost:/other/path
>
> If you do this incorrectly, you could have unwritable filepaths, but
> that’s the situation you were already in, so you are no worse off!
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:
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
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
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 ...
> Thanks for considering.
>
> Best,
>
> JD
Best regards, Michael.
- No longer accessible host paths, JD Smith, 2019/11/02
- Re: No longer accessible host paths, Michael Albinus, 2019/11/03
- Re: No longer accessible host paths, JD Smith, 2019/11/03
- Re: No longer accessible host paths,
Michael Albinus <=
- Message not available
- Re: No longer accessible host paths, Michael Albinus, 2019/11/04
- Re: No longer accessible host paths, JD Smith, 2019/11/04
- Re: No longer accessible host paths, Michael Albinus, 2019/11/05
- Re: No longer accessible host paths, Michael Albinus, 2019/11/08
- Re: No longer accessible host paths, JD Smith, 2019/11/08
- Re: No longer accessible host paths, Michael Albinus, 2019/11/09
- Re: No longer accessible host paths, Michael Albinus, 2019/11/09
- Re: No longer accessible host paths, Michael Albinus, 2019/11/10
- Re: No longer accessible host paths, JD Smith, 2019/11/10
- Re: No longer accessible host paths, Michael Albinus, 2019/11/10