From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r113958: * minibuffer.el (completion--sifn-requote): Bind `non-essential'. Date: Thu, 22 Aug 2013 20:40:35 +0200 Message-ID: <87zjs9sh5o.fsf@gmx.de> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1377196854 11427 80.91.229.3 (22 Aug 2013 18:40:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Aug 2013 18:40:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 22 20:40:55 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VCZoT-0005yw-Lo for ged-emacs-devel@m.gmane.org; Thu, 22 Aug 2013 20:40:53 +0200 Original-Received: from localhost ([::1]:33156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCZoT-0001Uz-B1 for ged-emacs-devel@m.gmane.org; Thu, 22 Aug 2013 14:40:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCZoL-0001Uo-4p for emacs-devel@gnu.org; Thu, 22 Aug 2013 14:40:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCZoF-0003VI-9G for emacs-devel@gnu.org; Thu, 22 Aug 2013 14:40:45 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:62533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCZoE-0003Uq-UN for emacs-devel@gnu.org; Thu, 22 Aug 2013 14:40:39 -0400 Original-Received: from detlef.gmx.de ([91.41.141.45]) by mail.gmx.com (mrgmx002) with ESMTPS (Nemesis) id 0MMk99-1V8yeA194B-008cQ4 for ; Thu, 22 Aug 2013 20:40:38 +0200 In-Reply-To: (Stefan Monnier's message of "Thu, 22 Aug 2013 11:39:24 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:VeawA5S9jh8OcW7V34fAbVXyERWG3fYkVhDwWGyfeeHODVQJgve zPf+/gwZIiYIxde2os/aFymWkvgjBorrktBjx5WrYRh3H9/IVBtqJJvhGgyEV+mV6BPQ4nQ EeRn4/0sj0ogVovF/rMRGPgqHfiC6kpJ/aY6dMbDvBWc5f4CTZAC+ltIzt0iT1n35g1YfDp Sv5bkxn7pjT7zsLxVziyw== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.18 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162981 Archived-At: Stefan Monnier writes: >> Hmm. Why not signalling a pilot error, when a user applies "C-x >> f /sudo: RET"? It's not so different from the case the user has >> described in Bug#13900, which was the trigger to introduce the rule >> "host name != any method name". > > Then how about a different take on the problem: Tramp shouldn't signal > an "ambiguous file name" error when its behavior would be the same > either way. AFAIK substitute-in-file-name would return the same result > regardless of whether "/ssh:vagrant@192.168.10." is taken to be the file > "vagrant@192.168.10." in host "ssh" or access via ssh to host > "192.168.10.". Well, I could try to implement it in Tramp's `substitute-in-file-name' handler. However, I don't know which other functions with file name handlers are called when applying `minibuffer--complete-and-exit'. Let's see. (But it would be a just a hack) >> And it is bound to t only in icomplete.el, ido.el and rfn-eshadow.el, as >> yet. For exactly that reason: "please relax your tests and connection >> actions when performing file name completion or minibuffer decoration". > > The key word is "decoration" and not "completion". The present case is > about completion and not about decoration. > >> That doesn't sound ugly to me. > > It's called `non-essential' and not `tramp-inhibit' specifically because > I don't want icomplete.el and friends to have Tramp-specific hacks > in them. If you start abusing it on the premise that "that's how I use > it in Tramp", then it defeats the whole purpose. I don't want to spread trampish functionality somewhere else. But Tramp is broken by design: its syntax is ambigous, and sometimes Tramp cannot decide merely on the file name syntax whether this is the intended file name to be used on the wire. That's why it needs advice from the caller: "don't take this file name serious, I'm not interested in a working connection yet". That does not mean that Tramp wouldn't use an established connection if it exists already, it simply means that Tramp doesn't open a new connection if there isn't one. Minibuffer decoration is such a case where Tramp needs such an advice, and file name completion is another case. An incomplete file name does not need a working connection. Consequently, some predicates used in file name completion (like `file-exists-p') will give proper results only when the connection is established finally. But that might be acceptable. `non-essential' bound to t looks to me perfect for such an advice. If you believe it is an abuse of that variable, please give me a hint how Tramp could get such an advice otherwise. It is not "that's how I use it in Tramp". Since I hack for Tramp (11 years these days) this problem eats a serious amount of my maintenance time. I would be more than happy if it could be solved finally, somehow. Due to the misdesigned Tramp file name syntax, I don't see how to solve it inside Tramp. > Stefan Best regards, Michael.