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 16:10:34 -0700 Message-ID: <006d01c928d1$e7709200$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> 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 1223422230 15182 80.91.229.12 (7 Oct 2008 23:30:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2008 23:30:30 +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 01:31:25 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 1KnM1U-0000SW-3m for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Oct 2008 01:31:24 +0200 Original-Received: from localhost ([127.0.0.1]:35374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnM0Q-0003Cf-AQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 19:30:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnM0B-00034D-AK for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 19:30:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnM0A-00033E-F4 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 19:30:02 -0400 Original-Received: from [199.232.76.173] (port=36869 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnM09-00032o-JY for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 19:30:01 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:41730) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnM08-00038e-VZ for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 19:30:01 -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 m97NTv9F021344; Tue, 7 Oct 2008 16:29:59 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m97NK3Be019061; Tue, 7 Oct 2008 16:20:03 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Oct 2008 23:20: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 submit@emacsbugs.donarmstrong.com id=B.122342115117808 (code B ref -1); Tue, 07 Oct 2008 23:20:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 7 Oct 2008 23:12:31 +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 m97NCSo2017802 for ; Tue, 7 Oct 2008 16:12:29 -0700 Original-Received: from mx10.gnu.org ([199.232.76.166]:46672) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1KnLgr-0002aH-AT for emacs-pretest-bug@gnu.org; Tue, 07 Oct 2008 19:10:05 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1KnLhW-0007SM-45 for emacs-pretest-bug@gnu.org; Tue, 07 Oct 2008 19:10:49 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:38395) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnLhV-0007SA-MI for emacs-pretest-bug@gnu.org; Tue, 07 Oct 2008 19:10:45 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m97NAYiP009069; Tue, 7 Oct 2008 17:10:34 -0600 Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m97NAWFp018462; Tue, 7 Oct 2008 17:10:33 -0600 Original-Received: from dradamslap1 (/141.144.57.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Oct 2008 23:10:32 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AckowOLCLcgQtrveQs+w8f+z1X3xUgACqrTA 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-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-CrossAssassin-Score: 2 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 07 Oct 2008 19:30: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:21246 gmane.emacs.pretest.bugs:23178 Archived-At: > No you completely misunderstand, there's no relationship > between the "prefix" stuff and the directory info that > used to be fudged into PREDICATE. > > That directory info that used to be passed in PREDICATE is > now passed via buffer-local variables instead. Right. I did misunderstand that. You use the boundaries thing to pass along the context "(" for Info file name "(em", but you don't use it to pass the directory for file-name completion - and I do see (and did, but forgot) how you pass the directory in the latter case. My bad about that part. 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. The directory used for completion is separate and kept separate from the input, the completion candidates, and the completion result, which are all relative names. The result of hitting RET for `read-file-name' is an absolute file name, but the result of the completion itself - e.g. the result of `read-file-name-internal', is just the relative name. 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. Why couldn't we treat this completion the same way we treat file-name completion? I'm not saying that we must fix this for Info for Emacs 23.1 - I agreed that such generalized Info completion is for the wishlist now. I'm only asking why it shouldn't be the policy that the invariants are respected. Is there any case where they logically *cannot* be respected? I think that's what I'm missing: an example where there is no way to avoid a mismatch between a completion per `try-completion' and a completion per `all-completions'. It seems to me that the invalidation for "(em" was introduced by treating "(" as a prefix (using the boundaries mechanism) and not treating "(emacs)" the same way we treat directories for file-name completion. That might be all we want to do for now, but is Info completion a case where there is no choice but to invalidate the invariants? IIUC, completion of "(em" in Info now treats the "(" part as contextual boundary info to be temporarily ignored while completing against a list of Info file names. For that treatment, you use `boundaries'. And it is that treatment that introduces a difference between the completions of `all-completions', which are Info file names such as "emacs-mime", and the completions of `try-completions', which are names such as "(emacs-mime)". (In Emacs 22, before `boundaries', a different treatment was used here, which also invalidated the invariants.) Is this description of the situation correct? Please think of what I'm writing not as disputing but as trying to understand. I believe you that you know what you're talking about here. ;-) I just want to understand it better.