From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r113958: * minibuffer.el (completion--sifn-requote): Bind `non-essential'. Date: Thu, 22 Aug 2013 11:39:24 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1377185984 11731 80.91.229.3 (22 Aug 2013 15:39:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Aug 2013 15:39:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 22 17:39:46 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 1VCWzB-00005w-6Q for ged-emacs-devel@m.gmane.org; Thu, 22 Aug 2013 17:39:45 +0200 Original-Received: from localhost ([::1]:60469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCWzA-0007mp-KI for ged-emacs-devel@m.gmane.org; Thu, 22 Aug 2013 11:39:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCWyz-0007mG-KT for emacs-devel@gnu.org; Thu, 22 Aug 2013 11:39:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCWys-00079h-9E for emacs-devel@gnu.org; Thu, 22 Aug 2013 11:39:33 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:5692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCWys-00079T-4D for emacs-devel@gnu.org; Thu, 22 Aug 2013 11:39:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+LNT/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFHO+LNT/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="22978212" Original-Received: from 206-248-179-83.dsl.teksavvy.com (HELO pastel.home) ([206.248.179.83]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 Aug 2013 11:39:18 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C8DF46627C; Thu, 22 Aug 2013 11:39:24 -0400 (EDT) In-Reply-To: (Michael Albinus's message of "Thu, 22 Aug 2013 11:50:46 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:162978 Archived-At: >> So we're in the middle of minibuffer--complete-and-exit which calls >> try-completion. That's very definitely not "non-essential". > Not `minibuffer--complete-and-exit'. But the completion functions I > would call non-essential. Huh? You did notice that the command's name has "-complete-" in it, right? > As said, I don't know too much about completion code in minibuffer.el > (and the functions' docstrings don't help much). Maybe > `completion--sifn-requote' is not suited to bind `non-essential'. But > there are other `completion--*' functions in the backtrace, up to > `minibuffer--complete-and-exit'. They're all just computing the completion. >> Yes, it could be a "complete but ambiguous/erroneous" file name, but it >> could also be a "not yet complete file name". So maybe, if there's no >> ":" nor "/" after "/ssh:", we should refrain from signaling an error. > 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.". > I don't know which further plans you have with `non-essential'. But its > setting to t is acknowledged so far only in ange-ftp and Tramp. So far. > 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. Stefan