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 09:47:03 -0700 Message-ID: <000f01c927d3$2963f850$c2b22382@us.oracle.com> References: <00b801c92674$b294d550$0200a8c0@us.oracle.com><014a01c9276c$1f45f740$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 1223313239 17526 80.91.229.12 (6 Oct 2008 17:13:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2008 17:13:59 +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 Mon Oct 06 19:14:56 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 1Kmtc1-0000pZ-9k for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2008 19:11:13 +0200 Original-Received: from localhost ([127.0.0.1]:40099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kmtax-0007xI-FH for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2008 13:10:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kmtas-0007uc-24 for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 13:10:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kmtaq-0007tS-JR for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 13:10:01 -0400 Original-Received: from [199.232.76.173] (port=44597 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kmtaq-0007tG-7S for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 13:10:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:38564) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kmtap-0000M8-MN for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2008 13: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 m96H9vB2022473; Mon, 6 Oct 2008 10:09:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m96Gt5E8018347; Mon, 6 Oct 2008 09:55:05 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 06 Oct 2008 16:55:05 +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.122331165216927 (code B ref 1085); Mon, 06 Oct 2008 16:55:05 +0000 Original-Received: (at 1085) by emacsbugs.donarmstrong.com; 6 Oct 2008 16:47:32 +0000 Original-Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m96GlT3m016921 for <1085@emacsbugs.donarmstrong.com>; Mon, 6 Oct 2008 09:47:30 -0700 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m96GlDuP017708; Mon, 6 Oct 2008 11:47:14 -0500 Original-Received: from acsmt705.oracle.com (acsmt705.oracle.com [141.146.40.83]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m96Gl312015370; Mon, 6 Oct 2008 10:47:09 -0600 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Oct 2008 16:47:03 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcknwTuqz9TgAZhvRC2OKvwBqUlgHQAC+Wzw 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.6 (newer, 3) Resent-Date: Mon, 06 Oct 2008 13: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:21179 gmane.emacs.pretest.bugs:23165 Archived-At: > From: Stefan Monnier Sent: Monday, October 06, 2008 7:37 AM > > It has been true in general. It has just been false for a > > few exceptions. > > Different uses of "in general". Yes. It is true almost all of the time, but not all of the time. I think it is false for some cases where it could be made true. > > 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. Agreed. > Currently all-completions returns the first list and > the `boundary' thingy can indicate that the missing prefix is > "/toto/". In passing: The `boundary' thingy needs to be documented. It is not obvious how to use it or how it works. > You want to change that so that all-completions returns the > second list, 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. I believe it should be possible for the functions that perform completion to DTRT even for cases like file-name completion, so that the user's input corresponds to the candidates in *Completions* and to `all-completions' and `try-completion'. I'm not sure how that should best be done, but I think it should be possible to take care of the directory part without it becoming part of each completion candidate. That's kind of what we do now anyway. Perhaps you have an idea about how to do it? > 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? Consistency. Ability to manipulate or reason about completion code and treat it in a general manner. See next. > > 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. Can you explain a bit how to do that? Will that enable respect of the invariants I mentioned? > >> 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, That's OK. What I'm thinking of is having both `all-completions' and *Completions* display, say, relative file names, as now, and having `try-completion' also use and return a relative file name, but have them all somehow deal with the directory. The directory can be passed separately, no? > so aesthetic and convenience may impose other constraints. I'm not claiming a simple, immediate solution. I'm asking you to think about it. > >> 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. I don't see it as such good use. To me it is a bug. I sent a fix. > > 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". Argument `code' = t in the source code (and in the fix I sent). > > 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. No, admittedly it is not directly related. The question at hand is how to handle completion of just the Info file-name part, e.g. `(emacs-mime)'. To me, the user's input should match what s?he sees in *Completions* (with parens), and they should both reflect both `all-completions' and `try-completion'. > > (mapcar (lambda (file) (concat "(" file ")")) ctwc)) > > That's not correct when completing "(/usr/shar". Is that possible? Could you elaborate? What should the code do here? I don't claim that the fix I sent is 100%. It seems to DTRT, but it might require some tweaking. In any case, the `all-completions' part of the current code is currently broken and requires some fix. It doesn't make sense for input of `(emacs)' with CODE = t to return nil (no completions). `all-completions' should be able to return the complete set of file-name completions in that case. IOW, (Info-read-node-name-1 "(emacs)" nil t) should not return nil, meaning no completions - it should return the list of all completions, ("(emacs)"), just as (Info-read-node-name-1 "(emacs)" nil nil) returns "(emacs)". > > 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. Could you maybe explain some of your thoughts on it? Share some of your internal head-banging behind the design and implementation? I don't doubt that you've thought it over - how about sharing some of the thoughts and considerations?