Re: No longer accessible host paths

[Michael Albinus]

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

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

>         * So in my opinion, interactive calling of
>         set-visited-file-name seems like an unnecessary and confusing
>         duplication.  If I wanted to change the file *name* itself, I
>         could first change the host and directory using
>         tramp-rename-these-files, then C-x w it easily enough.  I
>         can’t think of a changing network scenario which would require
>         the *filename* to change.  It seems to me just
>         (set-visited-file-name buffer-file-name) should suffice for
>         all reasonable scenarios.  * Then no-confirm can apply to just
>         one thing: the default-rename-alist.  Right now there is no
>         prefix or no-confirm based method to call change-these-files
>         that avoids the unnecessary final `set-visited-file-name`
>         prompt.
>
>     Well, maybe we need another user option in order to distinguish
>     the two confirmation cases. `tramp-confirm-rename-file-names', if
>     set to t (the default), triggers the confirmation of
>     `set-visited-file-name'. A value of nil doesn't ask for. The
>     NO-CONFIRM argument is not needed anymore, we just use the prefix
>     argument of the command to avoid confirmation of the target path.
>
> That could work.  NO-CONFIRM does double duty as well with the alist. 

Not anymore.

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

>        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:/"

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

>         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 :-(

> Best,
>
> JD

Best regards, Michael.