bug#23006: 25.0.92; Loading Tramp breaks pcomplete in eshell-mode

[Michael Albinus <michael.albinus@gmx.de>]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> So maybe we need two different flags for Tramp: One to suppress opening a
>> new connection under any circumstances, and one flag to tell Tramp that
>> we are in the file name completion business, and it shall open a new
>> connection only it is safe (like seeing a slash in the local file name
>> part). Remember my scenario about ediff'ing remote files; I *want* file
>> name completion for the second file, even if there's no established
>> connection yet.
>
> Do you have any reason to expect that `non-essential' would be set to
> non-nil in that context?

Yes. The reason is that it has been always my understanding of
non-essential. See the discussion between Stefan and me six years ago,
when non-essential was born.

Tramp needs an indication that file name completion is in
progress. Otherwise, it would regard remote file names like "/adb:" safe
to be handled, and it would report an error then. Again, we are speaking
about arbitray file name operations but file-name-all-completions and
file-name-completion. Every completion package is free to call any magic
file name operation while file name completion is in progress, it isn't
forbidden anywhere.

> From your description, I see the reason for the connection to be
> established. It does not describe the slash-related caveats, and what
> would make you avoid establishing a connection, e.g. in the case of
> ediff.

I start to believe that we need two different indications. Let's assume
non-essential provides two different non-nil values, `strict' and
`best-effort'. (I don't insist in these names, I even don't insist it
must be indicated by non-essential. Any other variable would do).

In the `strict' case, Tramp must not open a new connection under any
circumstances. That's your idle timer case. There might be also other
cases, but it shall be used with care, because it restricts Tramp's
convenience.

In the `best-effort' case, Tramp is said that file name completion is in
progress, and it shouldn't open a new connection even if the file name
to be completed looks like a valid remote file name, like "/adb:". Tramp
opens a new connection only when it is safe, for example when it has
detected a slash in the local file name part of the file name to be
completed. That's the case when the user has hit TAB, for example. File
name completion packages, which bind non-essential to true these days,
shall change this to a binding of `best-effort'.

>> Still, it would be nice to have let-bound non-essential in order to get
>> an effect.
>
> It's not that simple. First of all, I came to this bug from a report
> by a company-mode user. And apparently we're getting the same error,
> through pcomplete-completion-at-point, from two different user
> interactions: one that should set `non-essential' (like Stefan
> suggested), that would be the "idle completion", and one that
> shouldn't set `non-essential', that would be manually initiated
> completion.
>
> So setting `non-essential' in pcomplete-completion-at-point, or one of
> its callees, looks like a wrong solution to me.
>
> But getting back to this bug report:
>
> I've just typed `M-x pcomplete', which should be a good indicator that
> I probably want to be prompted for credentials, if
> required. `non-essential' should be nil in this scenario. And yet, I
> shouldn't see that error.

`strict' is superior to `best-effort'. Coming back to this bug report, I
would expect that non-essential is bound to `best-effort' somewhere in
pcomplete or the involved completion package(s). When one of these
packages determine, that they run in an idle timer (or something
comparable dangerous), they should overwrite this binding of non-essential
with `strict'.

Best regards, Michael.