From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: widget-choice-action Date: Tue, 2 Aug 2005 11:25:49 -0500 (CDT) Message-ID: <200508021625.j72GPnv09648@raven.dms.auburn.edu> References: <200508021349.j72DnQ208932@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1123000357 31569 80.91.229.2 (2 Aug 2005 16:32:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2005 16:32:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 18:32:30 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dzzfg-0002Px-W2 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2005 18:31:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DzziO-0005oq-Sd for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2005 12:34:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DzzhY-0005VM-1K for emacs-devel@gnu.org; Tue, 02 Aug 2005 12:33:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DzzhL-0005Nz-Td for emacs-devel@gnu.org; Tue, 02 Aug 2005 12:33:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DzzhL-0005ME-3A for emacs-devel@gnu.org; Tue, 02 Aug 2005 12:32:59 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dzzms-0001mS-GR for emacs-devel@gnu.org; Tue, 02 Aug 2005 12:38:43 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j72GPrqt006964; Tue, 2 Aug 2005 11:25:54 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j72GPnv09648; Tue, 2 Aug 2005 11:25:49 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: abraham@dina.kvl.dk In-reply-to: (message from Per Abrahamsen on Tue, 02 Aug 2005 17:31:51 +0200) 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:41429 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41429 Per Abrahamsen wrote: The real solution is that when you have overlapping types in a choice widget, the most specific *must* be listed first. That is exactly what my defcustom below does. The duplicated value is nil (as it most often is, in practice). The most explicit is the const nil. It is listed first. 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. Are you sure about that? It might have been what the code was intended to do, but is that really what it actually does? Maybe my fix is not the correct one, but something needs to be fixed. 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. That is actually completely OK. In many cases, as in the example below, the only reason to select a less explicit choice is to change the value. But there is often no natural explicit :value to select, so one wants to leave the :value nil, even though saving that value is equivalent to selecting the explicit nil and, if that is done and the Custom is revisited, the explicit nil _should_ be shown. Things will probably be clearer on the concrete example. We are talking about the new indicate-buffer-boundaries defcustom, which in today's CVS is in the fringe group. (There are unrelated bugs hat still need to be fixed. Loading fringe.el will override any values you saved for `indicate-buffer-boundaries' and `indicate-empty-lines' and I would like to get rid of the (redundant) `fringe-indicators' defcustom. (indicate-buffer-boundaries fringe (choice (const :tag "No indicators" nil) (const :tag "On left, with arrows" left) (const :tag "On right, with arrows" right) (set :tag "Pick your own design" :value ((t . nil)) :format "%{%t%}:\n%v\n%d" :doc "You can specify a default and then override it \ for individual indicators. Leaving \"Default\" unchecked is equivalent with specifying a default of \"Do not show\"." (choice :tag "Default" :value (t . nil) (const :tag "Do not show" (t . nil)) (const :tag "On the left" (t . left)) (const :tag "On the right" (t . right))) (choice :tag "Top" :value (top . left) (const :tag "Do not show" (top . nil)) (const :tag "On the left" (top . left)) (const :tag "On the right" (top . right))) (choice :tag "Bottom" :value (bottom . left) (const :tag "Do not show" (bottom . nil)) (const :tag "On the left" (bottom . left)) (const :tag "On the right" (bottom . right))) (choice :tag "Up arrow" :value (up . left) (const :tag "Do not show" (up . nil)) (const :tag "On the left" (up . left)) (const :tag "On the right" (up . right))) (choice :tag "Down arrow" :value (down . left) (const :tag "Do not show" (down . nil)) (const :tag "On the left" (down . left)) (const :tag "On the right" (down . right)))) (other :tag "On left, no arrows" t)) "22.1") With this (the current code) everything works fine. But originally, I did not have the `:value (t . nil)', so the actual :value was nil, which was intended. (t . nil) happens to be equivalent in its effects with nil, but is a formally different value, which is why I can use this workaround. But such a workaround will not always be available. Without the `:value (t . nil), if the current value shown is the explicit nil and you select "Pick your own design", it works. But if any other value is currently shown (whether it is the actual value of the option, or whether it is just edited but not set does not appear to matter) and you try to select "Pick your own design", the explicit nil actually gets selected. It is irrelevant that if I would immediately save the option, the explicit nil and the unedited "Pick your own design" interface would save the same value. Clearly, I selected "Pick your own design" to edit that widget, not to save the blank interface. Sincerely, Luc.