customize value hooks - be able to edit color samples in different ways...

[Drew Adams]

For after the release -

People have commented on the ugliness of Customize and the difficulty of
navigating it without getting lost and frustrated. Another, more important
(I think) way in which Customize can be improved is to provide for better
interaction when defining and modifying values. You sometimes change a
value, go off and do something to see if it's a good value, then come back
and change it again. Tightening this tweaking loop would improve things
quite a bit.

Even when you don't need to leave Customize to judge a value, tweaking it
can be unnecessarily difficult. Consider colors. You choose a color by
entering its name or its RGB hex string. You can't compare the color you're
tweaking to others, except perhaps by referring to `list-colors-display',
which is limited to named colors. There are ways to pick a color that are
simpler, more interactive, and more flexible. Some such color tweakers are
available here and there in Emacs libraries, but there is no simple way of
plugging them in, so that Customize can take advantage of them.


1. How about making the "sample"s for Customize faces (and other color
fields) be potential buttons that let you change the color using some hook
function?

IOW, have a hook attached to the "sample" text, so that if the hook happens
to be defined (non-nil), the text becomes a button that calls the hook
function (to let you change the color). Different libraries could be used to
provide different color-modification UIs (functions).

There are various possibilities for interactive functions that change a
color. My own code defines two:

 - A color palette that lets you define or modify a color in various ways.
Pretty standard, outside of Emacs.

 - DoReMi, which lets you modify a color using the arrow keys or a mouse
wheel.

I'm not proposing using my code (FSF will not accept it anyway, since my
employer won't sign the papers), but such a functionality is useful
generally, and providing the hooks would encourage development of UI
extensions to Customize.

Note that a hook function here could even open a menu that provides more
than one value-tweaking method (interface). One type of menu choice might be
whether you want incremental tweaking to change only the sample or the face
itself: automatic, on-the-fly "Set for Current Session". (DoReMi, for
instance, changes the face as you tweak.) In the latter case, Customize
needs to be made aware of the "external" change, and accept it as its own -
but that's another story...


2. More generally, such hooked Customize fields need not be limited to
colors; the same principle applies to other kinds of values. For example, a
numeric field might hook to a function that lets you use a slider or a
DoReMi-style function to adjust the value incrementally. Some such UIs might
show you the potential (or the real) effect of tweaking elsewhere in Emacs.


In sum: Use Customize as a UI framework, letting users call upon other
functions to provide different value-choice or value-modification
interfaces. Open up the customization UI to other libraries, as far as value
manipulation is concerned.

A side benefit of this would be to reduce the need to change Customize
itself to provide such UI improvements. Over time, UI extensions that are
appreciated could be incorporated into Emacs without adding them to the
Customize code. Even then, users could continue to experiment with different
UI functions.

My guess (but I'm no expert on widgets or Customize) is that such a  hook
mechanism 1) would not be difficult to implement, 2) would be clean, and 3)
would provide a great, immediate benefit, opening Customize to better
value-defining UIs. Some of those might even be domain-specific, taking into
account the particular field being modified (as opposed to just its type).

WDOT?