From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#23006: 25.0.92; Loading Tramp breaks pcomplete in eshell-mode Date: Sun, 20 Mar 2016 18:17:47 -0400 Message-ID: References: <871t7d4ion.fsf@gmx.de> <877fh0hovs.fsf@gmx.de> <756f60a7-bdf9-a806-b9d6-dbf17f0ebaab@yandex.ru> <87y49gg9sm.fsf@gmx.de> <845ef936-dec1-eac9-db2a-f2bb25f3a830@yandex.ru> <87egb8faxv.fsf@gmx.de> <8760wj3eks.fsf@gmx.de> <8760wj4jvp.fsf@gmx.de> <871t7650th.fsf@gmx.de> <87io0i32sq.fsf@gmx.de> <871t752nme.fsf@gmx.de> <87fuvlup8l.fsf@gmx.de> <87zitsubm0.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458512308 4777 80.91.229.3 (20 Mar 2016 22:18:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Mar 2016 22:18:28 +0000 (UTC) Cc: 23006@debbugs.gnu.org, Dmitry Gutov To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 20 23:18:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ahlfs-00017G-AT for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Mar 2016 23:18:16 +0100 Original-Received: from localhost ([::1]:54669 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahlfr-0007GA-Mq for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Mar 2016 18:18:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahlfl-0007G4-W1 for bug-gnu-emacs@gnu.org; Sun, 20 Mar 2016 18:18:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahlfe-0003Cf-F6 for bug-gnu-emacs@gnu.org; Sun, 20 Mar 2016 18:18:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahlfe-0003Cb-BY for bug-gnu-emacs@gnu.org; Sun, 20 Mar 2016 18:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ahlfe-0007tI-4w for bug-gnu-emacs@gnu.org; Sun, 20 Mar 2016 18:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Mar 2016 22:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23006-submit@debbugs.gnu.org id=B23006.145851227230317 (code B ref 23006); Sun, 20 Mar 2016 22:18:02 +0000 Original-Received: (at 23006) by debbugs.gnu.org; 20 Mar 2016 22:17:52 +0000 Original-Received: from localhost ([127.0.0.1]:55947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ahlfU-0007su-8g for submit@debbugs.gnu.org; Sun, 20 Mar 2016 18:17:52 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:56151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ahlfR-0007sj-GR for 23006@debbugs.gnu.org; Sun, 20 Mar 2016 18:17:51 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u2KMHlLE003059; Sun, 20 Mar 2016 18:17:48 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id BEFC7AE240; Sun, 20 Mar 2016 18:17:47 -0400 (EDT) In-Reply-To: <87zitsubm0.fsf@gmx.de> (Michael Albinus's message of "Sun, 20 Mar 2016 21:40:23 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5616=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5616> : inlines <4536> : streams <1606175> : uri <2170846> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115192 Archived-At: >> 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 =E0 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