From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 37b88d7: Fix bug#23006 Date: Fri, 10 Mar 2017 05:34:03 -0500 Message-ID: References: <20170309184457.29604.13048@vcs0.savannah.gnu.org> <20170309184458.08C9725FCF@vcs0.savannah.gnu.org> <87k27xfo3q.fsf@detlef> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1489142106 715 195.159.176.226 (10 Mar 2017 10:35:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Mar 2017 10:35:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 10 11:35:01 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmHsw-0007kh-VY for ged-emacs-devel@m.gmane.org; Fri, 10 Mar 2017 11:34:59 +0100 Original-Received: from localhost ([::1]:38391 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmHt2-0000Ih-S0 for ged-emacs-devel@m.gmane.org; Fri, 10 Mar 2017 05:35:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmHsR-0000IZ-JD for emacs-devel@gnu.org; Fri, 10 Mar 2017 05:34:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cmHsN-0001qm-ND for emacs-devel@gnu.org; Fri, 10 Mar 2017 05:34:27 -0500 Original-Received: from [195.159.176.226] (port=53802 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cmHsN-0001q9-F7 for emacs-devel@gnu.org; Fri, 10 Mar 2017 05:34:23 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cmHsD-0003J0-It for emacs-devel@gnu.org; Fri, 10 Mar 2017 11:34:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 44 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:WrUlZ0L18lKrpurKKpsFQDJfNAY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212878 Archived-At: > If you believe this is wrong, then Tramp needs another variable for such > a trigger. As we did agree originally in > . > The idea to take `non-essential' instead came later from you. IIUC the problem comes from the following: 1- in the process of performing completion, the completion code will end up using "subparts" of a filename. More specifically, the user may write something like "/ssh:foo:bar" but the completion code somehow ends up invoking file functions (and hence Tramp) on "/ssh:foo". 2- For historical reasons, Tramp wants to allow users to write "/ssh:foo" to access files on the "ssh" host. So in order for Tramp to figure out where the "/ssh:foo" that it received should be treated as "foo on ssh" or as "incomplete host foo via ssh", you need to try and figure out where we're in case 1 or case 2, and you try to do that using some heuristic, part of which is to look at `non-essential'. Sadly, `non-essential' is not there for that purpose, so it is only somewhat correlated with the info you want, but is not a reliable indicator (neither sufficient nor necessary). I see 2 ways out of this problem: - Introduce a new variable which indicates we're performing completion. I'm not sure exactly what "performing completion" means precisely, but maybe binding it in completion-file-name-table would be sufficient for Tramp's needs. - Get rid of this historical syntax. We could still accept "/ssh:./foo" (or maybe even "/ssh:foo/bar", tho this one looks more risky) to access the "ssh" host, which seems like a very minor annoyance. I'm strongly in favor of the second option: while the ambiguity of "/ssh:foo" is only known to bite us in the case of completion, I'd be surprised if there aren't other cases where it hurts. Also the way Tramp currently behaves subtly differently while completing than in other contexts is a source of complexity of bugs which I'd rather eliminate (I remember some problems linked to such discrepancies around file-name-directory). Stefan