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: Tue, 07 Oct 2008 17:07:08 -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> 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 1223415027 26399 80.91.229.12 (7 Oct 2008 21:30:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2008 21:30:27 +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 Tue Oct 07 23: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 1KnK9C-00026i-J1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 23:31:15 +0200 Original-Received: from localhost ([127.0.0.1]:47699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnK88-0008OI-Vp for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 17:30:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnK83-0008Mr-IK for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 17:30:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnK82-0008Lv-Ni for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 17:30:02 -0400 Original-Received: from [199.232.76.173] (port=50318 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnK82-0008Lf-6n for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 17:30:02 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:37648) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnK81-0002uB-BO for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 17: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 m97LTvAE024029; Tue, 7 Oct 2008 14:29:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m97LF4kV020573; Tue, 7 Oct 2008 14: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: Tue, 07 Oct 2008 21: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 1085-submit@emacsbugs.donarmstrong.com id=B1085.122341363519234 (code B ref 1085); Tue, 07 Oct 2008 21:15:04 +0000 Original-Received: (at 1085) by emacsbugs.donarmstrong.com; 7 Oct 2008 21:07:15 +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 m97L7AG1019228 for <1085@emacsbugs.donarmstrong.com>; Tue, 7 Oct 2008 14:07:12 -0700 Original-Received: from alfajor.home (vpn-132-204-232-223.acd.umontreal.ca [132.204.232.223]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m97L79lL014302; Tue, 7 Oct 2008 17:07:09 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id 916E01C54B; Tue, 7 Oct 2008 17:07:08 -0400 (EDT) In-Reply-To: <003f01c9289c$5e271a80$0200a8c0@us.oracle.com> (Drew Adams's message of "Tue, 7 Oct 2008 09:47:17 -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 RV3120=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 07 Oct 2008 17: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:21241 gmane.emacs.pretest.bugs:23177 Archived-At: > "png-file" cannot be a directory, we are no longer talking about "like > all other file completions in Emacs" - where subdirectory names *are* > treated as file names. See http://en.wikipedia.org/wiki/PNG to learn what is a PNG file. > I think you've extrapolated from the file-completion case, but you've ignored > the fact that Emacs file-completion does treat directory names as valid file > names (for completion). You talk as if there was only a single form of file-name completion in Emacs, even though it's clearly not the case: it depends on the kind of file name you want to get. It may be restricted to directories, to files of a particular kind, etc... > Is "png-file" like file-completion or something different? Do you want > to let directories be completed or not? These are design decisions for > png-file completion. But I see no reason that "png-file" couldn't be > defined to be able to complete as one would like. If you want to be able to enter /usr/share/foo/bar/toto/foo.png with completion, that means that all-completions should either return all png files in your file system (this is impractical) or that it returns both png files and directories, so that you can complete "/u" to "/usr/", etc... But that doesn't mean that test-completion should accept "/usr/". > Perhaps I'm missing some of what you're saying here; dunno. What I'm saying is that your invariant is too restrictive and it makes sense to break it sometimes. So it's not a valid invariant and code should not rely on it being true. > "(emacs)" in Info would be treated the same way, and there too you > could consider it a prefix, so the same mechanism could be used to do > the wish-list completion we discussed, no? Very much so. > But I don't see why this extra information should always be considered > a prefix. It could be anything really. It's just something that lets > COLLECTION (aka TABLE) do its job and something that we do *not* want > to appear as a prefix of each completion. In the case of file-name and > Info node completion you *could* consider it as in some sense an > invisible prefix (but not a prefix that is part of each completion), > but you need not think of it that way. I have no clue what you're talking about. > How about making the boundaries feature less dependent on treating > this separate info as a (pseudo-)prefix? Instead of a string, it could Because it wouldn't provide the info you need to write drew-all-completions. > The problem, as I see it, is that among STRING, PREDICATE, and ACTION, > there is no explicit provision for passing the additional info > (e.g. directory). So we have fudged. We use PREDICATE for the dir. No: "we useD PREDICATE for the dir". This is being phased out. > Or we fudge ACTION so it can sneak in the dir as > a pseudo-prefix. Fudging ACTION is maybe better than fudging > PREDICATE, and it leaves more room for manoeuver and engenders less > conflict, but it is still a fudge. And if ACTION is fudged to do this, > that still doesn't mean that the extra info should be treated as > a prefix (string, start, end, etc.). Neither should be fudged. The extra info can be passed via buffer-local variables, or stored inside the function (e.g. using lexical-let). > Shouldn't we fix this right, so the extra info that the COLLECTION > function needs is passed as an arg in its own right? I agree with your > changes (still in progress, IIUC) to clean up PRED so it is always > a predicate. But it seems to me that sneaking the extra info in in the > form of a "prefix" string inside ACTION is also an ugly hack. Why > don't we try to come up with something that fits legacy but also DTRT? Oh, is that what you're talking about? 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. Stefan