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: Sun, 27 Sep 2009 14:24:57 -0400 Message-ID: References: <137402B99D584CEE9AF2E4B23116527A@us.oracle.com> <622F55DCAB0343E9827BF3FD038C3361@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 1254075920 8099 80.91.229.12 (27 Sep 2009 18:25:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2009 18:25:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 27 20:25:13 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 1MryQp-0003kA-49 for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 20:25:12 +0200 Original-Received: from localhost ([127.0.0.1]:56315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MryQo-0001ZM-G1 for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 14:25:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MryQj-0001Z7-5o for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:25:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MryQd-0001XO-Ft for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:25:03 -0400 Original-Received: from [199.232.76.173] (port=52199 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MryQd-0001XF-8Y for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:24:59 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:36244 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MryQc-0005Ec-Ui for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:24:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUEANtKv0pFpYq6/2dsb2JhbACBUdB7hB4Fh30 X-IronPort-AV: E=Sophos;i="4.44,461,1249272000"; d="scan'208";a="46673420" Original-Received: from 69-165-138-186.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.186]) by ironport2-out.pppoe.ca with ESMTP; 27 Sep 2009 14:24:57 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 35E5980C4; Sun, 27 Sep 2009 14:24:57 -0400 (EDT) In-Reply-To: <622F55DCAB0343E9827BF3FD038C3361@us.oracle.com> (Drew Adams's message of "Sat, 26 Sep 2009 17:02:24 -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:115693 Archived-At: > After successful completion, set a global variable to the symbol that > represents the completion style. Returning info via a global variable is evil. > We already return the set of completions, and you've hacked that list > to also carry the base size in its last cdr. No, that was an ugly hack I managed to get rid of before releasing Emacs-23. > This third piece of info about the completion state can be returned in > a global variable. (It can be at least as important as the base > size, IMO.) Reality check: you can't even come up with a concrete case where it would be useful, so how can you claim it can be at least as important as the base-size which has been needed since the introduction of choose-completion (Emacs-21? Emacs-20?) > Also, it is somewhat inconvenient to have `completion-styles-alist' as > a defvar, not a defcustom. It is the real fulcrum for all of the > code. It is baked once by Emacs development, and then it is used as > the basis for the rest. User customization of `completion-styles' is > limited to choosing among predefined styles. A defcustom? It contains pointers to functions and those functions use a non-trivial calling convention, so there's very little chance you'll be able to add entries there without writing Lisp code. `completion-styles-alist' is definitely not a candidate for defcustom. > It would be better to have a single option that lets users both (a) > choose the styles to use and (b) define new styles (their names and > their defining completion functions). IOW, combine > `completion-styles-alist' with `completion-styles' as a single option > that users can customize. And where do you keep the list of options from which they can choose? > That way, the code would still automatically adjust to the possible set of > completion styles, but those styles would not be limited to choices from a > predefined list. Users could still just as easily add or remove predefined > styles, but they could also more easily add their own. How hard can it be to add their new style to completion-styles-alist and then to completion-styles as well? Especially compared to the amount of work required in writing that new style? I must be misunderstanding something. >> It might be easy in 99% of the cases, depending on exactly what >> you want. > See above. The "above" didn't tell me what you want to do. Stefan PS: FWIW, I can think of at least one case where the "file vs envvar" information could potentially be used. So maybe if you try hard enough, you too can come up with an example.