From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Per Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: widget-choice-action Date: Tue, 02 Aug 2005 17:31:51 +0200 Organization: The Church of Emacs Message-ID: References: <200508021349.j72DnQ208932@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1122997055 20184 80.91.229.2 (2 Aug 2005 15:37:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2005 15:37:35 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 17:37:34 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dzynk-0000vQ-NK for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2005 17:35:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DzyqS-0004gC-F0 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2005 11:38:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dzyog-0003hk-TC for emacs-devel@gnu.org; Tue, 02 Aug 2005 11:36:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DzyoY-0003de-90 for emacs-devel@gnu.org; Tue, 02 Aug 2005 11:36:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DzyoX-0003cn-JH for emacs-devel@gnu.org; Tue, 02 Aug 2005 11:36:21 -0400 Original-Received: from [130.225.40.227] (helo=sheridan.dina.kvl.dk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dzywa-0004iG-MY for emacs-devel@gnu.org; Tue, 02 Aug 2005 11:44:41 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by sheridan.dina.kvl.dk (Postfix) with ESMTP id 1971913CFA; Tue, 2 Aug 2005 17:31:52 +0200 (CEST) Original-Received: from sheridan.dina.kvl.dk ([127.0.0.1]) by localhost (sheridan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13556-09; Tue, 2 Aug 2005 17:31:51 +0200 (CEST) Original-Received: by sheridan.dina.kvl.dk (Postfix, from userid 304) id 16DD913CEA; Tue, 2 Aug 2005 17:31:51 +0200 (CEST) Original-To: Luc Teirlinck X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dina.kvl.dk 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:41425 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41425 It was RMS who wrote code, but since I'm CC'ed, I'll contribute with my recollection of it (which may be entirely wrong). Luc Teirlinck writes: > This seems very counterintuitive and I had to struggle > with this in the new indicate-buffer-boundaries defcustom, although I > finally found an acceptable workaround (but that was a coincidence and > I would rather not have used the workaround, although it is not too > bad). What did you first try to do, what did you end up with? > If the user selects a choice from a value menu, he expects to > get that choice, regardless of whether the default :value of that > choice is identical with the previous value or not. The "previous value" is not used. It compares the value of the choice the user selected, with the *new* value of the widget, which are supposed to be the same. I can imagine some cases where they are different, and for those cases there are no guarantee that the new value of the widget will actually fit the type of the explicit chosen widget. So these should be ignored. I.e., please don't apply your patch. ... I'm in general very suspicious of any customize type that need the :explicit-choice functionality in order to work. A choice widget will normally select the first choice that match the value. :explicit-choice overrides that, so an later choice can be selected even if a prior choice matches. However, if you save the option and enter customize again, the first match will be used, thus the choice you see will not be the one you saved. Thus :explicit-choice often just hides a problem in a custom type long enough for the developer not to discover it, but not long enough for the user to avoid being bitten by it. The real solution is that when you have overlapping types in a choice widget, the most specific *must* be listed first. This (choice string sexp); OK and not (choice sexp string); BAD: "string" will never be selected ; implicit, as any string is also a sexp