all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: widget-choice-action
Date: Tue, 2 Aug 2005 11:25:49 -0500 (CDT)	[thread overview]
Message-ID: <200508021625.j72GPnv09648@raven.dms.auburn.edu> (raw)
In-Reply-To: <rjmzo0icd4.fsf@sheridan.dina.kvl.dk> (message from Per Abrahamsen on Tue, 02 Aug 2005 17:31:51 +0200)

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.

  reply	other threads:[~2005-08-02 16:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-02 13:49 widget-choice-action Luc Teirlinck
2005-08-02 15:31 ` widget-choice-action Per Abrahamsen
2005-08-02 16:25   ` Luc Teirlinck [this message]
2005-08-02 20:20   ` widget-choice-action Luc Teirlinck
2005-08-02 21:44   ` widget-choice-action Luc Teirlinck
2005-08-03 10:50     ` widget-choice-action Per Abrahamsen
2005-08-03 14:59       ` widget-choice-action Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200508021625.j72GPnv09648@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.