[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 2 Aug 2005 11:25:49 -0500 (CDT)
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.
(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))
: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))
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