GNU bug report logs -
#23006
25.0.92; Loading Tramp breaks pcomplete in eshell-mode
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Mon, 14 Mar 2016 02:02:01 UTC
Severity: normal
Found in version 25.0.92
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>> 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
This bug report was last modified 8 years and 68 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.