From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: how to determine the current table (really) being used for minibuffer completion? Date: Fri, 25 Sep 2009 21:53:53 -0400 Message-ID: References: <137402B99D584CEE9AF2E4B23116527A@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1253930052 15338 80.91.229.12 (26 Sep 2009 01:54:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Sep 2009 01:54:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 26 03:54:05 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MrMU9-0002na-5m for ged-emacs-devel@m.gmane.org; Sat, 26 Sep 2009 03:54:05 +0200 Original-Received: from localhost ([127.0.0.1]:43752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrMU8-0001wN-6f for ged-emacs-devel@m.gmane.org; Fri, 25 Sep 2009 21:54:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MrMU3-0001w8-S8 for emacs-devel@gnu.org; Fri, 25 Sep 2009 21:53:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MrMTz-0001vw-7U for emacs-devel@gnu.org; Fri, 25 Sep 2009 21:53:59 -0400 Original-Received: from [199.232.76.173] (port=36847 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrMTz-0001vt-3w for emacs-devel@gnu.org; Fri, 25 Sep 2009 21:53:55 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:48871 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MrMTy-0005gp-Gv for emacs-devel@gnu.org; Fri, 25 Sep 2009 21:53:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAFMRvUpFpYq6/2dsb2JhbACBUdV2hB4Fh30 X-IronPort-AV: E=Sophos;i="4.44,454,1249272000"; d="scan'208";a="46632841" Original-Received: from 69-165-138-186.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.186]) by ironport2-out.pppoe.ca with ESMTP; 25 Sep 2009 21:53:53 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 37BF380B1; Fri, 25 Sep 2009 21:53:53 -0400 (EDT) In-Reply-To: <137402B99D584CEE9AF2E4B23116527A@us.oracle.com> (Drew Adams's message of "Fri, 25 Sep 2009 14:22:26 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115649 Archived-At: > How I used to do what? There is no concrete example. Please, then say clearly that your problem is hypothetical, that will help us answer your questions more directly. > So you've confirmed what I said: one cannot know. The request is to be > able to know. IOW, to be able to have some finer-grain knowledge of > the completion state. Define what you mean by "have some finer-grain knownledge of the completion state". I think this request is like a solution waiting for a problem. So once we find a concrete problem, we'll know better how to solve it. But in the abstract like that, it's really unclear what kind of solution would be needed/possible. > The point is that now there can be radically different kinds of > completion that are used, all within the same > `read-file-name-internal' (for example). That has always been a possibility. Maybe this is used a bit more now, tho. > I would like to be able to know which phase of that completion > processing I'm in, When? Who's "I"? Do you mean, given the position of point which kind of completion will take place? The closest right now is to use completion-boundaries, which won't tell you what completion table will be used, but at least it'll tell you which part of the buffer around point will be "affected". > I would like, for instance (just an example), to be able to distinguish > file-name completion per se from env var completion, both of which are now > included as part of "file-name" completion in a larger sense. completion-boundaries can help you do that. But again, without knowing to what purpose you want to distinguish those two cases, it's hard to know what would really be a good answer. > Only in a general way. `foo' or `read-file-name-internal' is the > overall completion function, to be sure, but the completion processing > is now decomposed into several distinct cases (as you say, next). For > `read-file-name-internal', these are > `completion--embedded-envvar-table' and `completion--file-name-table'. > `read-file-name-internal' doesn't really call directly for any > low-level completion act (e.g. `try-completion') anymore. read-file-name-internal is pretty much the only one that I changed in this way, BTW. It can now complete either files or env-vars. In the future it will probably also be able to complete ~ user names. >> > So not only is checking `minibuffer-completion-table' against >> > `read-file-name-internal' useless, >> Comparing functions is usually a bad idea. Sometimes, >> there's not much else we can do, admittedly. > The Emacs code still compares `minibuffer-completion-table' against > `read-file-name-internal', in particular, in many locations. Not sure how you define "many", but my grep found only one place where we do it: in complete.el which could advise read-file-name-internal instead (but since it's on the way to obsolescence, it doesn't matter much either way). > I assume that all of those occurrences still work as intended. ;-) Why wouldn't they? ;-) BTW, all the uses I've ever found (other than complete.el's) were changed to use minibuffer-completing-file-name or to work in all cases. > It is a general request. We have plenty of real concrete problems to address and improvements to implement, so yours will inevitably end up at the very bottom of the lot. > I obviously don't have a great feel for how to best implement what I'm > asking for or how best to use it. Come back when you do know. Stefan