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: Mon, 06 Oct 2008 10:37:28 -0400 Message-ID: References: <00b801c92674$b294d550$0200a8c0@us.oracle.com> <014a01c9276c$1f45f740$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 1223304934 17729 80.91.229.12 (6 Oct 2008 14:55:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2008 14:55:34 +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 Mon Oct 06 16:56:30 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 1KmrQW-0000BW-Gs for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2008 16:51:13 +0200 Original-Received: from localhost ([127.0.0.1]:49071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmrPQ-00007d-HS for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2008 10:50:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmrPN-00006g-5O for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 10:50:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmrPM-000063-D4 for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 10:50:00 -0400 Original-Received: from [199.232.76.173] (port=40130 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmrPL-00005y-VC for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 10:49:59 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:46836) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmrPL-0003UN-Ca for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 10: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 m96Envfx019394; Mon, 6 Oct 2008 07:49:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m96Ej4a2018375; Mon, 6 Oct 2008 07:45:04 -0700 X-Loop: don@donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 06 Oct 2008 14:45: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 1085-submit@emacsbugs.donarmstrong.com id=B1085.122330385716997 (code B ref 1085); Mon, 06 Oct 2008 14:45:04 +0000 Original-Received: (at 1085) by emacsbugs.donarmstrong.com; 6 Oct 2008 14:37:37 +0000 Original-Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m96EbUYw016989 for <1085@emacsbugs.donarmstrong.com>; Mon, 6 Oct 2008 07:37:31 -0700 Original-Received: from alfajor.home (vpn-132-204-232-40.acd.umontreal.ca [132.204.232.40]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m96EbTRO021655; Mon, 6 Oct 2008 10:37:29 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id B0B931C3E8; Mon, 6 Oct 2008 10:37:28 -0400 (EDT) In-Reply-To: <014a01c9276c$1f45f740$0200a8c0@us.oracle.com> (Drew Adams's message of "Sun, 5 Oct 2008 21:29:28 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3118=0 X-CrossAssassin-Score: 2 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Mon, 06 Oct 2008 10:50:00 -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:21173 gmane.emacs.pretest.bugs:23162 Archived-At: > It has been true in general. It has just been false for a few exceptions. Different uses of "in general". > I think it should be true always. There are 2 different needs. For the user's convenience, the *Completions* buffer should only list "foo for fot" rather than "/toto/foo /toto/for /toto/fot" and similarly for various other completion cases. Currently all-completions returns the first list and the `boundary' thingy can indicate that the missing prefix is "/toto/". You want to change that so that all-completions returns the second list, which still requires some way to figure out that the part that should be stripped from display is "/toto/". Efficiency and history are on the side of the current behavior. > It should be possible to bring those exceptions into the fold. For what benefit? > One should be able to use `all-completions' to construct a cons > completion table that is equivalent to the original TABLE argument, > regardless of how TABLE is defined (e.g. function, obarray). Use the `boundary' thingy. And note that this is new in Emacs-23. In previous versions of Emacs there simply was no standardized way to do that reliably. >> In practice the main case where this "invariant" does not hold is when >> the completion table is the one for file names, where all-completions >> returns names that do not "full" (i.e. do not include the directory >> name). > Why shouldn't it be true in that case also? It isn't now, but it could > be, could it not? File name completion could be made to keep the same > user behavior it has now and still respect the invariants I mentioned. Because the output of all-completions has historically been used for the *Completions* output, so aesthetic and convenience may impose other constraints. >> For code that needs to live with this problem (e.g. minibuffer.el), >> Emacs-23 introduces a new way to call the completion table >> function with a `boundary' argument. > Why should `Info-read-node-name-1' in particular "need to live with > this problem"? Info-read-node-name-1 does not "live with this problem". On the contrary it makes good use of this freedom. > Why shouldn't it return, for a CODE of t, a valid list > of completions satisfying the invariants I mentioned? Why not do > it right? I don't know what you mean by "a CODE of t". > Ideally (this part is for the wish list), we would provide completion > not only for input such as `(ema', giving all-completions `("(emacs)" > "(emacs-mime)")', but also for input such as `(emacs)Mac', giving > all-completions `("(emacs)Mac Directories" "(emacs)Mac > Environment"...)'. It's indeed on the wishlist. I'm pretty sure there's a TODO about it in the code. But it has noting to do with the dicsussion at hand. > (mapcar (lambda (file) (concat "(" file ")")) ctwc)) That's not correct when completing "(/usr/shar". > I hope you'll reconsider the policy wrt support for the invariants > I suggested, instead of encouraging (yes) n'importe quoi. I have banged my head against this problem for a long time, while working on the minibuffer.el code (and its predecessors), so I don't expect to change my mind any time soon. The only thing you'd accomplish with your proposal is "change", but it would just shift the problems from one place to another without any actual benefit. Stefan