Re: No longer accessible host paths

[Michael Albinus]

JD Smith <address@hidden> 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 the prefix, but it’s
> now quite irrelevant given your prompt 2 interface updates (see
> below).

Well, the docstring says

--8<---------------cut here---------------start------------->8---
Interactively, TARGET is selected from `tramp-default-rename-alist'
without confirmation if the prefix argument is non-nil.
--8<---------------cut here---------------end--------------->8---

So yes, if you use the prefix, and you haven't a matching entry in
`tramp-default-rename-alist', you'll get this error. I've extended the
error message to

--8<---------------cut here---------------start------------->8---
There is no target specified.  Check `tramp-default-rename-alist' for a proper 
entry.
--8<---------------cut here---------------end--------------->8---

> Thanks, this is very *very* much improved!  I can hit “!” to “do
> everything I said”, skip any file selectively, edit, or abort any
> rename. And yes, even change the filename itself if I wanted to for
> some reason.  This satisfies everything we both want I think.

Thanks for the feedback. A step forward!

> One small quibble is that “q” is not really “do not change any of the
> buffers” but “do not change any further buffers”.  I.e. if you already
> said “y”, those earlier buffers in the list remain renamed.  It might
> be preferable to revert those original changes with a “q”, as in
> “never mind I want to abort this whole renaming thing”.

As said, I've stolen the prompt style from dired. And there, "q" means
indeed “do not apply the function to further files”. I don't want to
confuse users with a different behavior here.

As compromise, I've added another y-or-n prompt after hitting "q" (or "ESC"):

--8<---------------cut here---------------start------------->8---
Do you want to revert applied changes? (y or n)
--8<---------------cut here---------------end--------------->8---

I have also removed the special C-g handling, since we have now the "n"
and "q" choices.

>     I haven't touched the doc today. Maybe you could provide some
>     phrases,
>     how it would read better?
>
> @code{target} must be a directory name, which could be remote
> (including remote directories Tramp infers by default, such as
> /method:host:)

Applied. I've added also the %m pattern for the method to
`tramp-default-rename-alist', in case someone wants to use it.

> The only thing I have left to sort out is that Ido is truly terrible
> with this.  C-f is the normal “get out of Ido and give me a normal
> prompt”, but it by default is only bound to that when you are at the
> end of the mini buffer text.  So our new method of putting point at
> the host defeats that.  And I think it is responsible for adding a
> useless trailing slash (ala /method:host/:) but perhaps Tramp is doing
> that.  So I always have to fix up something that’s already a mess,
> like:
>
>     /ssh:user@host/:/home/user/:/home/user/
>
> I can’t even defeat Ido with something like:
>
>       (add-to-list 'ido-read-file-name-non-ido 'tramp-rename-files)
>       (add-to-list 'ido-read-file-name-non-ido
>     'tramp-rename-these-files)
>
> Because it is so “smart” it notices your predicate is file-directory-p
> and offers a special directory-reading interface, not falling back to
> a normal read-file-name.  I’m not familiar with the non-essential
> concept; would it work in rename-these as well?

`non-essential' isn't specific to Ido. It just prevents Tramp from
opening a new connection when it isn't established yet, and when there's
no localname part yet. whoever calls Tramp.

I have *no* idea how ido works internally. Does it help to set
`ido-enable-tramp-completion' to nil?

Also, in Emacs 27.0.50 there is a new `fido-mode'. "Fido" stands for
"Fake Ido", and it promises an Ido interface, but using the default
completion machinery of Emacs. I haven't tried this either, but maybe it
could be an alternative.

If you don't find a working configuration, I will ban Ido completion
competely from reading source and target in the interactive
case. ALternatively, I could try to underfstand what Ido does. But this
is not my core competence in Emacs; I cannot pomise too much.

> Thanks again,
>
> JD

Best regards, Michael.