Re: No longer accessible host paths

JD Smith writes: Hi, > FYI, this was implemented in bug=38231. So eventually the following > will “fix” ido’s issues with rename-* directory reading, by disabling > it: > > (add-to-list 'ido-read-file-name-non-ido 'tramp-rename-files) > (add-to-list 'ido-read-file-name-non-ido >

Re: No longer accessible host paths

> On Nov 16, 2019, at 10:54 AM, JD Smith wrote: > > I sent a bug report to bug-gnu-emacs with a suggested simple patch. FYI, this was implemented in bug=38231 . So eventually the following will “fix” ido’s issues with rename-* directory re

Re: No longer accessible host paths

> On Nov 16, 2019, at 10:45 AM, Michael Albinus wrote: > > JD Smith writes: > >> `ido-everywhere` is the culprit. If I disable it, things work as >> expected. Most ido users have it enabled I’d guess. >> >> I can also work to get ido patched so that it respects >> `ido-read-file-name-non-

Re: No longer accessible host paths

JD Smith writes: Hi, > I like the final y/n to fully abort. The C-h help form is the > problem: "ESC or `q' to not change any of the buffers,” should read > "ESC or `q' to quit without changing further buffers”. Applied. > `ido-everywhere` is the culprit. If I disable it, things work as > ex

Re: No longer accessible host paths

JD Smith writes: Hi, > No, this is in a remote tramp buffer. Steps to reproduce: > > 1 Load a tramp buffer, which is not specified in the > default-rename-alist. > 2 C-u M-x tramp-rename-these-files > 3 Error: “There is no target specified” > > It’s possible I’ve misinterpreted the point of t

Re: No longer accessible host paths

> On Nov 15, 2019, at 7:54 AM, Michael Albinus wrote: > > JD Smith writes: > > Hi, > >> Thanks, tried this in the new version. C-u M-x >> tramp-reload-these-files simply complains about no target and aborts. > > I guess you have called `tramp-rename-these-files' on a local buffer, yes? > I

Re: No longer accessible host paths

JD Smith writes: > One more small bug I discovered when changing networks. In > `tramp-rename-read-file-name-dir`, `file-remote-p` returns nil when > you are truly disconnected, since the CONNECTED argument is t. This > signals an error on rename. The connection doesn’t persist for bad > hosts

Re: No longer accessible host paths

JD Smith writes: Hi, > Thanks, tried this in the new version. C-u M-x > tramp-reload-these-files simply complains about no target and aborts. I guess you have called `tramp-rename-these-files' on a local buffer, yes? It is a user-error. And this is intended: `tramp-rename-these-files' works on

Re: No longer accessible host paths

One more small bug I discovered when changing networks. In `tramp-rename-read-file-name-dir`, `file-remote-p` returns nil when you are truly disconnected, since the CONNECTED argument is t. This signals an error on rename. The connection doesn’t persist for bad hosts. Probably safe to mak

Re: No longer accessible host paths

> On Nov 14, 2019, at 9:19 AM, Michael Albinus wrote: > > JD Smith 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

Re: No longer accessible host paths

Michael Albinus writes: Hi, > 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. Impleme

Re: No longer accessible host paths

JD Smith 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

Re: No longer accessible host paths

> On Nov 14, 2019, at 8:01 AM, Michael Albinus wrote: > > JD Smith mailto:jdtsm...@gmail.com>> 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 hav

Re: No longer accessible host paths

JD Smith writes: > Clarifying that: the culprit is the CONNECTED argument to > `file-remote-p`. It’s easy for this to be nil while you still want to > rename the host. So perhaps we shouldn’t require it to be CONNECTED. But the CONNECTED argument doesn't influence, whether `file-remote-p' give

Re: No longer accessible host paths

JD Smith writes: Hi, > Impressions of `tramp-rename-these-files` (which I think you made at > my prompting… thanks!): > > * 1st Prompt: > > * Ido really works poorly with this style prompt, but a simple C-f > gets you to a normal completion. I fear this is nothing I can fix. I don't use Ido,

Re: No longer accessible host paths

JD Smith writes: > And one more little bug: if you try to change host but timeout, > `file-remote-p` no longer things of the file as remote, even though it is > `tramp-tramp-file-p`. Then the following: > > (regexp-quote (file-remote-p source nil t > > throws an error,

Re: No longer accessible host paths

Clarifying that: the culprit is the CONNECTED argument to `file-remote-p`. It’s easy for this to be nil while you still want to rename the host. So perhaps we shouldn’t require it to be CONNECTED.

Re: No longer accessible host paths

And one more little bug: if you try to change host but timeout, `file-remote-p` no longer things of the file as remote, even though it is `tramp-tramp-file-p`. Then the following: (regexp-quote (file-remote-p source nil t throws an error, since `file-remote-p` is n

Re: No longer accessible host paths

On Nov 13, 2019, at 10:15 AM, Michael Albinus wrote: Hi, > FTR, I've renamed the functions to `tramp-rename-files' and > `tramp-rename-these-files'. This seems to fit better the purpose, I > believe. > > If there are no serious complaints, I'll merge them to Emacs 27.0.50 > over the weekend. B

Re: No longer accessible host paths

Hi, FTR, I've renamed the functions to `tramp-rename-files' and `tramp-rename-these-files'. This seems to fit better the purpose, I believe. If there are no serious complaints, I'll merge them to Emacs 27.0.50 over the weekend. Bug fixing will still be possible, there's even no pretest of Emacs 2

Re: No longer accessible host paths

JD Smith writes: Hi, > I still believe renaming *this remote* is truly a single prompt > operation. It would signal an error if called in a non-tramp > buffer. But otherwise, tramp fully knows the /method:badhost for the > currently visited file. Whether this-remote is a standalone command > o

Re: No longer accessible host paths

> On Nov 11, 2019, at 7:55 AM, Michael Albinus wrote: > > JD Smith writes: > > Hi, > >> 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 >> wi

Re: No longer accessible host paths

JD Smith writes: Hi, > 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 t

Re: No longer accessible host paths

> On Nov 10, 2019, at 12:36 PM, Michael Albinus wrote: > > JD Smith mailto:jdtsm...@gmail.com>> 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

Re: No longer accessible host paths

Michael Albinus writes: Hi, > 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:/tmp/ RET > Enter new Tramp connection: /ssh: ;; complete with "new" to > Enter new

Re: No longer accessible host paths

JD Smith 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 wit

Re: No longer accessible host paths

> On Nov 10, 2019, at 10:12 AM, Michael Albinus wrote: > > Michael Albinus 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 "Se

Re: No longer accessible host paths

Michael Albinus 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 wi

Re: No longer accessible host paths

Michael Albinus writes: Hi, >> One ingredient I haven’t yet tested is when the badhost is truly >> inaccessible, does it still hang if you forget to run rename-remote >> first (which seems inevitable to me). Can try that later. > > I've just checked, there are still some few actions on badhost.

Re: No longer accessible host paths

JD Smith writes: Hi, > Great, thanks. I took a look. For those of you following along, I > had to add the following to tramp-loaddefs.el to have the new > `tramp-rename-remote-files` command available through the normal > (patched) ELPA package: Yep. Alternatively, you could just load the tra

Re: No longer accessible host paths

Great, thanks. I took a look. For those of you following along, I had to add the following to tramp-loaddefs.el to have the new `tramp-rename-remote-files` command available through the normal (patched) ELPA package: (autoload 'tramp-rename-remote-files "tramp-cmds" "\ Replace in all buffers `

Re: No longer accessible host paths

Michael Albinus writes: Hi, > I hope to have a first version of tramp-rename-remote-files ready this > week, for playing. I would post a patch here, on top of Tramp 2.4.2.4. I have implemented a very first shot, see appended patch. It is pretty much alpha, it needs more careful testing, and it

Re: No longer accessible host paths

JD Smith writes: Hi, > 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 w

Re: No longer accessible host paths

yary writes: Hi yari, > I often have similar scenario of editing via TRAMP and then switching > networks, without those issues. I don't use ido, and I do have > auto-save to local /tmp for all my tramp buffers, setting "Auto Save > File Name Transforms" regexp - see > https://www.gnu.org/softwar

Re: No longer accessible host paths

I often have similar scenario of editing via TRAMP and then switching networks, without those issues. I don't use ido, and I do have auto-save to local /tmp for all my tramp buffers, setting "Auto Save File Name Transforms" regexp - see https://www.gnu.org/software/emacs/manual/html_node/tramp/Auto

Re: No longer accessible host paths

> On Nov 4, 2019, at 3:34 AM, Michael Albinus wrote: > > JD Smith mailto:jdtsm...@gmail.com>> writes: > > Hi, > > [pls keep tramp-devel@gnu.org in Cc. I'd > appreciate comments also from > other users] > >>> Well, I'm still playing with scenarios. For the time b

Re: No longer accessible host paths

JD Smith writes: Hi, [pls keep tramp-devel@gnu.org 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 pref

Re: No longer accessible host paths

JD Smith 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

Re: No longer accessible host paths

> On Nov 3, 2019, at 5:36 AM, Michael Albinus wrote: > > JD Smith mailto:jdtsm...@gmail.com>> writes: > > Hi, > >> Tramp (2.3.5.26.2) commonly hangs my Emacs session in the following >> scenario: >> >> * On an internal network at my work, I visit a file via: >> >> * /ssh:someinternalpath.foo

Re: No longer accessible host paths

JD Smith writes: Hi, > Tramp (2.3.5.26.2) commonly hangs my Emacs session in the following > scenario: > > * On an internal network at my work, I visit a file via: > > * /ssh:someinternalpath.foo.bar:file > > * I continue to edit the file after leaving the internal network. > * Later, on another