Re: No longer accessible host paths

[JD Smith]

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

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

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. 

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

I've implemented this; you might play with.

I’ll have a look. 

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

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. 

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.

Best,

JD