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

[Stefan Monnier]

>> But in that backtrace, it's OK for Tramp to open a new connection, since
>> the user hit TAB.
> Tramp does not know that the user hit TAB. It checks for `non-essential'.

Exactly: pcomplete tells Tramp that it's OK to prompt for a password by
*not* setting non-essential.  That's how Tramp can know.

>>>> And why would it be called `non-essential' instead of `in-completion'?
>>> I wanted to introduce `completion-only'.
>> The crucial distinction to be made is not between "performing
>> completion" and "not performing completion", but between "any normal
>> operation, including completion in response to TAB" and "side-operations
>> like on-the-fly completion à la icomplete or company or background data
>> collection (like semantic might perform)".
> I don't understand.  Tramp does not know where it has been called
> from. It operates stateless.  `non-essential' provides some context,
> that's all.

That's right.  What I'm pointing out is that the context that Tramp
needs is not "are we performing some kind of completion", but "are we
allowed to prompt the user for a password" (admittedly, `non-essential'
is not limited to "passwords" but more generally means that we should
stay discrete.  E.g. it also means we shouldn't block Emacs for too
long).

> I do not care desktop.el just now, it is the case we were discussing 6
> years ago. As of today, there is no other use case for `non-essential'
> in the codebase but the Tramp case.

Admittedly, the fact that the two sides (let-binder and var-reader)
don't agree on what that variable means, reduces its
usefulness significantly.

In my view, Tramp should never prompt the user for a password (nor
signal an error, tho emitting some warning message might be OK in some
cases) when non-essential is non-nil.

BTW, to clarify:
- Someone reported a bug about company's interaction with Tramp
  (presumably via pcomplete).  I suspect this should be fixed by having
  company bind non-essential and IIUC Dmitry did just that (don't know
  if it does/did fix the problem).
- As part of that company bug, this bug#23006 was filed, which has
  nothing to do with non-essential since it's about a user interaction
  which is "essential".  I've pointed out a few issues that have to do
  with the interaction between file-name-all-completions and
  file-name-directory which might lead to fixing this bug, but AFAIK
  this part of the discussion has not been followed yet.
Could we get back to the interaction between file-name-all-completions
and file-name-directory?


        Stefan