Re: widget-choice-action

[Per Abrahamsen]

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 <address@hidden> 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