From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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: Wed, 08 Oct 2008 12:10:01 -0400 Message-ID: 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> <008901c9290e$a3aa55a0$0200a8c0@us.oracle.com> Reply-To: Stefan Monnier , 1085@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1223483937 3604 80.91.229.12 (8 Oct 2008 16:38:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2008 16:38:57 +0000 (UTC) Cc: 1085@emacsbugs.donarmstrong.com, emacs-pretest-bug@gnu.org To: "Drew Adams" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 08 18:39:53 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 1KnbyV-0003UQ-2J for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Oct 2008 18:33:24 +0200 Original-Received: from localhost ([127.0.0.1]:55117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnbxQ-0004bF-70 for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Oct 2008 12:32:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnbvR-0003W6-LL for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 12:30:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnbvK-0003R4-EO for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 12:30:08 -0400 Original-Received: from [199.232.76.173] (port=59219 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnbvJ-0003QD-Gx for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 12:30:05 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:46272) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnbvI-0007zS-1L for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2008 12:30:04 -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 m98GTvqY017382; Wed, 8 Oct 2008 09:29:59 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m98GF4Qe013798; Wed, 8 Oct 2008 09:15:04 -0700 X-Loop: don@donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 08 Oct 2008 16:15:04 +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 submit@emacsbugs.donarmstrong.com id=B.122348221313106 (code B ref -1); Wed, 08 Oct 2008 16:15:04 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 8 Oct 2008 16:10:13 +0000 Original-Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m98GA5cU012670 for ; Wed, 8 Oct 2008 09:10:06 -0700 Original-Received: from mail.gnu.org ([199.232.76.166]:50413 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1KnbZd-0007oc-Ro for emacs-pretest-bug@gnu.org; Wed, 08 Oct 2008 12:07:41 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Knbbw-0002VN-8W for emacs-pretest-bug@gnu.org; Wed, 08 Oct 2008 12:10:05 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:17012 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Knbbw-0002V4-02 for emacs-pretest-bug@gnu.org; Wed, 08 Oct 2008 12:10:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAEADh47EjO+IH3/2dsb2JhbACBcr02gWqBBw X-IronPort-AV: E=Sophos;i="4.33,379,1220241600"; d="scan'208";a="28159974" Original-Received: from 206-248-129-247.dsl.teksavvy.com (HELO pastel.home) ([206.248.129.247]) by ironport2-out.teksavvy.com with ESMTP; 08 Oct 2008 12:10:02 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C81438568; Wed, 8 Oct 2008 12:10:01 -0400 (EDT) In-Reply-To: <008901c9290e$a3aa55a0$0200a8c0@us.oracle.com> (Drew Adams's message of "Tue, 7 Oct 2008 23:25:20 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-CrossAssassin-Score: 2 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Wed, 08 Oct 2008 12:30:08 -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:21279 gmane.emacs.pretest.bugs:23183 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. > 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. Not if the relative file name includes a slash. > (try-completion "icicles." 'read-file-name-internal nil) gives "icicles.el". That's just a happy corner case. We're discussing the general case. >> > 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? We use it for file-name completion just the same. If you're in the particular case where the file name has no directory component, then the prefix is the empty string so you may get fooled into thinking that it's not used, but it is. Stefan