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: Mon, 6 Oct 2008 21:42:21 -0700 Message-ID: <001901c92837$16b82910$0200a8c0@us.oracle.com> References: <00b801c92674$b294d550$0200a8c0@us.oracle.com><014a01c9276c$1f45f740$0200a8c0@us.oracle.com><000f01c927d3$2963f850$c2b22382@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 1223356220 10266 80.91.229.12 (7 Oct 2008 05:10:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2008 05:10:20 +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 Tue Oct 07 07:11:16 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 1Kn4qp-0002oX-5S for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 07:11:15 +0200 Original-Received: from localhost ([127.0.0.1]:37087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kn4pl-0005da-5C for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 01:10:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kn4pe-0005bV-E6 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 01:10:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kn4pd-0005aQ-1T for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 01:10:01 -0400 Original-Received: from [199.232.76.173] (port=47963 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kn4pc-0005aG-J1 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 01:10:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:52202) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kn4pb-00055S-Ui for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 01:10:00 -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 m9759vAR006529; Mon, 6 Oct 2008 22:09:58 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m974o35j001077; Mon, 6 Oct 2008 21:50: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 04:50: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.122335458032299 (code B ref -1); Tue, 07 Oct 2008 04:50:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 7 Oct 2008 04:43:00 +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 m974gvne032293 for ; Mon, 6 Oct 2008 21:42:58 -0700 Original-Received: from mail.gnu.org ([199.232.76.166]:59802 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1Kn4N8-0007QT-Q8 for emacs-pretest-bug@gnu.org; Tue, 07 Oct 2008 00:40:34 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Kn4PM-0000Wg-RV for emacs-pretest-bug@gnu.org; Tue, 07 Oct 2008 00:42:53 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:32168) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kn4PM-0000VC-7u for emacs-pretest-bug@gnu.org; Tue, 07 Oct 2008 00:42:52 -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 m974gSTm031822; Mon, 6 Oct 2008 22:42:28 -0600 Original-Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m974gMmC004624; Mon, 6 Oct 2008 22:42:27 -0600 Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Oct 2008 04:42:22 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckoIWMx27MWbQG3QFueMxA5otXnDwAD/xbQ 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 01:10:01 -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:21201 gmane.emacs.pretest.bugs:23169 Archived-At: > From: Stefan Monnier Sent: Monday, October 06, 2008 7:06 PM > > > > You want to change that so that all-completions returns > > > the second list [i.e. list of absolute, not relative > > > file names] > > > No, not necessarily. I only want `try-completion', > > `all-completions' and `test-completion' to be on the same > > page, in the sense of the invariants I mentioned. > > Then I missed those invariants. > Could you spell them out again one by one? Actually, it was you who first used the term "invariants", referring presumably to the behavior I had described/requested. ;-) But without at first using that term, I did speak of invariants: 1. User's input should be a prefix of what it is completed to in the minibuffer, which should be the same as the common prefix of all its completions, the result of `try-completion': > M-: (try-completion "(el" 'Info-read-node-name-1) > > It returns "(elisp)", meaning that this is the common prefix of all > completions of "(el". [This is reasonable, and it satisfies the > requirement that "(el" is a prefix of "(elisp)".] 2. `all-completions' elements correspond to `test-completion': > And each of the completions returned by `all-completions' must > also satisfy `test-completion'. In particular, > (test-completion STRG (all-completions strg TABLE)) must always > return t, for all STRG and TABLE. In this case, for STRG = "(el" and > TABLE = `Info-read-node-name-1', it returns nil. 3. `all-completions' elements correspond to `try-completion': > the valid completions returned by `all-completions' have the > common prefix that is returned by `try-completion' (which > must in turn have the input as its prefix [see #1]). I don't know how independent these are; there is probably some overlap. But they seem like good rules to shoot for. > PS: Regarding the behavior of info completion for "(emacs)", I assume by that you mean completion of things like "(emacs)Mac O" to "(emacs)Mac OS" and even completion of "(emacs)" to all of the Emacs manual nodes (a la completion of a directory /some/dir/ for files). > it can't be done right until someone writes the relevant code. > Basically the current code doesn't know how to do completion > in this case, so try-completion can't return anything use[ful?], > and neither can all-completions, or test-completion. Yes, I realize that. The code I sent lets you complete just the file-name part - "(ema" to "(emacs" and "(emacs-" to "(emacs-mime"). That's as far as it goes. I even thought about temporarily moving to the manual and doing a node completion there, then prefixing each node by "(emacs)" etc. But aside from the ugliness of that approach and my laziness, I wasn't sure of the behavior I wanted. I think now that a straight analogy to file-name completion wouldn't be bad: "(emacs)Fo" in the minibuffer and all of the Emacs manual node names in *Completions* - without "(emacs)" prefix - just like for file names. Just as with file names, you could delete the default directory (manual's file name - "(emacs)" from the minibuffer if you wanted. Just as with file names, you could change the directory (manual's file) explicitly in the minibuffer. Yes, I know that these musings might seem to contradict some of the invariants mentioned above. I think that if Info node completion behaved just like file-name completion I'd be happy. Dunno. > The current code instead just tries to return something > that's safe: Safe = ? I don't follow. > try-completion returns the string unchanged, which indicates > that it's a valid completion and that there's > more completions out there; test-completion returns t to basically say > the same; I think they are OK. > and all-completions returns nil so that > minibuffer-completing-help doesn't give some bogus list > of completions. That's not good, I think. nil means there are no completions. > The try-completion and test-completion outputs are fairly reasonable. Yes. > The all-completions one is less satisfactory since returning nil seems > to imply that the input is not a valid completion, whereas > try-completion and test-completion say that it is. We agree. > Returning a list containing a copy of the input wouldn't > be right either since it would imply that the current > input is the sole completion. Agreed. That's why I fixed it to return the complete set of manuals (files): ("(emacs)" "(emacs-mime"). But it would be good to be able to complete beyond "(emacs)" to all of the Emacs manual nodes - like completing "/some/d" to "/some/dir/" and then completing that to all of the directory's files. > Basically, we'd need a special `dont-know' return value, > but it doesn't seem worth the trouble. I don't follow you there. What do you mean? All of the manuals (files) are known, and all of the nodes in each manual are known. So such completion should be possible. - Drew P.S. Could you explain a little about boundaries and what you meant about using that feature. This is not clear to me.