Re: No longer accessible host paths

On Nov 14, 2019, at 9:19 AM, Michael Albinus <address@hidden> wrote:

JD Smith <address@hidden> 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 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?)

Have you played with the new code? NO-CONFIRM does not exist any longer
as argument. Just the command's prefix arg is taken for decision,
whether you'll need to specify TARGET, or not.

I hope, the new interface answers some of your questions ...

Thanks, tried this in the new version. C-u M-x tramp-reload-these-files simply complains about no target and aborts. I’m happy to specify target (since unless I’ve pre-decided on a target via the alist, that’s definitely necessary). I just don’t want to set-visited-file-name them all. See below for (too much) more discussion on this point.

   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.

But then you have to confirm twice:

* 'y' for "I want to see and edit the file name"

* the file name itself.

I understand that your use case doen't expect to change the file
name. But other people might have different preferences, and I want to
be prepared.

I mean _substitute_ a y-or-n for the prompt. I tried the C-g method (which is like selecting “no”), and that works, leaving some buffers behind on an ala carte basis.

But I still maintain a random prompt saying "Set Visited File: /method:host:/common/path" is going to be *very* confusing to people. It still confuses me honestly. To understand what you are being asked (and why), you have to notice that the current buffer changed (if it did), and you may have many windows which means only one of them changed. And the prompt doesn’t mention at all *which* file you are setting the visited filename for, only the new host and directory path *which is the same for all files being changed* (for a reload-these anyway). So you have to somehow infer that by looking for a window with a potential active remote-file-visiting buffer.

To make this confusion concrete, here’s the actual workflow I get (for say 5 buffers on a single oldhost):

Visiting File /ssh:oldhost:/path/to/file1
[M-x tramp-rename-these-files]
“Change Tramp connection `/ssh:oldhost:/path/to/‘: /ssh/oldhost/:/path/to” (with point at the ‘/:’). OK good, this should work. Let me just...
Edit this to be "/ssh:newhost:/path/to/“ (removing the superfluous ‘/‘ before the final colon) [Ret]
“Set Visited file name: /ssh:newhost:/path/to/“. Hmmm, what is this? The filename is empty. Am I supposed to put a file name in? For which file? Maybe just hit return? Not clear. So let’s try return. [Ret]
“Set Visited file name: /ssh:newhost:/path/to/“. I already answered that. Why is it asking me the same questions again? Did my buffer in the small top left window change? I wasn’t watching I was reading the mini buffer. Maybe my keyboard malfunctioned. I’ll try that again... [Ret]
“Set Visited file name: /ssh:newhost:/path/to/“ OK I definitely hit return. This thing is really is a broken record. Maybe I should just cancel this whole thing... [C-g]
“Set Visited file name: /ssh:newhost:/path/to/“ OMG, it broke C-g. I’ll never escape. Despair.

And here’s the workflow I wish I had:

Visiting File [/ssh:oldhost:/path/to/]
M-x tramp-rename-these-files,
“Change Tramp connection in 5 buffers `/ssh:oldhost:/path/to/‘: /ssh/oldhost:/path/to”
edit this to be "/ssh:newhost:/path/another/“ [Ret] (no window buffers change…)
Message: “Tramp connection changed in 5 buffers to /ssh:newhost:/path/to/"

All of the complexity to me comes because the current command tries to overload two very different actions: 1) change method/host/common directory path and 2) change the actual filename. The latter isn’t really related to the thrust of this command, in my opinion. What filename changes would be precipitated by a changing network circumstance? And if you want to rename the file (not alter its method/host/directory path), you can simply C-x C-w after fixing up the host & directory paths.

Anyway, if you disagree entirely about this I’ll drop it, I just know in 2 weeks when I need to reach for this command, I’ll still be baffled by that 2nd prompt :).

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.

Yes, I offer both: RET to accept, or <edit> RET to change. An additional
y-or-n would be superfluous, I believe.

I've implemented this; you might play with.

I’ll have a look.

Pls. I'm interested in your feedback for what I've changed :-)

Sorry that I seem stuck on this 2nd prompt business. One real problem here is that “RET to accept” is by no means obvious, since it’s not clear what’s being asked for, and why. Probably hard to change set-visited-file-name’s prompt text….

      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).

But it is! If you dislike it, use "/ssh:method:host:/"

Fair enough. I guess most would imagine “the host part” and “the directory part” to be separated by the final colon. But this is just semantics.

       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.

You see me still inquiring. Use "/method:host:" instead, and if you
dislike default expansion, use "/method:host:/". I don't see how it
limits you.

Not a limitation just a confusion. Maybe a gentle reminder in the docs here that a path with nothing past the final colon constitutes a default directory on the 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.

Thanks for the offer. However, it's not a problem of testing. The
problem is inherent in the thread implementation of Emacs. When you have
two threads running in parallel, and bot query something from the
minibuffer, you cannot distinguish what comes from where. This has been
discussed in length on the emacs-devel mailing list, with no
solution. And so my work ist stalled :-(

From:	JD Smith
Subject:	Re: No longer accessible host paths
Date:	Thu, 14 Nov 2019 15:00:39 -0500