From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1 Date: Tue, 7 Oct 2008 23:25:20 -0700 Message-ID: <008901c9290e$a3aa55a0$0200a8c0@us.oracle.com> References: <00b801c92674$b294d550$0200a8c0@us.oracle.com><014a01c9276c$1f45f740$0200a8c0@us.oracle.com><000f01c927d3$2963f850$c2b22382@us.oracle.com><001901c92837$16b82910$0200a8c0@us.oracle.com><003f01c9289c$5e271a80$0200a8c0@us.oracle.com><006d01c928d1$e7709200$0200a8c0@us.oracle.com> Reply-To: Drew Adams , 1085@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1223448629 7548 80.91.229.12 (8 Oct 2008 06:50:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2008 06:50:29 +0000 (UTC) Cc: 1085@emacsbugs.donarmstrong.com, emacs-pretest-bug@gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 08 08:51:26 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KnSt7-0000rN-NW for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Oct 2008 08:51:14 +0200 Original-Received: from localhost ([127.0.0.1]:41287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnSs3-000864-LN for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Oct 2008 02:50:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnSrz-00084U-N6 for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 02:50:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnSrw-00080U-Vw for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 02:50:02 -0400 Original-Received: from [199.232.76.173] (port=50090 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnSrw-00080Q-Pg for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 02:50:00 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:19260) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnSrw-0007Gx-DW for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 02:50:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnSrv-0000AM-Ay for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 02:49:59 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m986nvMT000821; Tue, 7 Oct 2008 23:49:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m986Z3ZJ029855; Tue, 7 Oct 2008 23:35:03 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 08 Oct 2008 06:35:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1085 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1085-submit@emacsbugs.donarmstrong.com id=B1085.122344713328490 (code B ref 1085); Wed, 08 Oct 2008 06:35:03 +0000 Original-Received: (at 1085) by emacsbugs.donarmstrong.com; 8 Oct 2008 06:25:33 +0000 Original-Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m986PUM7028398 for <1085@emacsbugs.donarmstrong.com>; Tue, 7 Oct 2008 23:25:31 -0700 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m986PJT3007274; Wed, 8 Oct 2008 00:25:19 -0600 Original-Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m986PG1s022151; Wed, 8 Oct 2008 00:25:17 -0600 Original-Received: from dradamslap1 (/141.144.57.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Oct 2008 06:25:15 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acko7f8oySOautQgQpWYsnN9eYTkrAAHx5Sg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Resent-Date: Wed, 08 Oct 2008 02:50:02 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:21256 gmane.emacs.pretest.bugs:23180 Archived-At: > > I was following my analogy and thought that you did the > > same thing for both, using the directory part as a > > boundary/contextual "prefix" of the relative file name. > > > But IIUC, there is no invalidation of the invariants for > > file-name completion. > > Your 3rd invariant is invalidated because all-completions does not > return the directory part of a completion. Yes and no. If you use find-file, then yes, you're right, because it calls, in effect, try-completion passing an absolute file name: (try-completion "c:/mydir/icicles." 'read-file-name-internal nil) gives "c:/mydir/icicles.el", whereas, as you say, all-completions uses relative file names. But if you call try-completion directly using a relative file name, then it, just like all-completions, returns the completed relative file name - completed in the default directory. (try-completion "icicles." 'read-file-name-internal nil) gives "icicles.el". That was my point. If the directory information is passed separately, not included in the file name, then try-completion and all-completions use the same set of completions (relative file names). There is no invalidation of the invariant - the two coexist harmoniously - the completions for try-completion and for all-completions are the same. > > If you agree about that, then let's come back to "(em", > > which is a case, we agree, where the invariants are > > currently invalidated. IIUC, you say it is a > > case where the invariants *must* be invalidated. My > > question is why. I still have the same question - why? > > Why couldn't we treat this completion the same way we treat > > file-name completion? > > We do treat it identically. Not if I understand correctly. Isn't it true that we use the boundary thing (with prefix "(") for the Info file/node completion, and we don't use it for file-name completion? And doesn't the use of that feature invalidate the invariant?