RE: customize value hooks - be able to edit color samples in differentways...

[Drew Adams]

        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.

    Specifying colors is a specialized area.  I think we should
    acknowledge that at the outset.  Implementing a convenient way in
    Emacs to specify a color would be a nice thing to do, and it could be
    used in Customize as well as perhaps elsewhere.

Agreed.

    I see no need to worry about hooks for calling this.

See below. (Not to worry, BTW.)

    Once someone has implemented a nice way to specify a color,
    we can make things call it.

Good.

        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.

    This focus on how users select among various methods of specifying
    certain data is misplaced.  The real issue is to implement a nice
    method for various kinds of data.  First let's get ONE such method.
    To worry about how we will deal with having more than one for a given
    type of data is getting ahead of the game.

No, that was not the real issue I raised, in any case.

The idea was to open the Customize UI to any number of UI extensions that
might be available now or in the future - from anywhere: internal or
external code. If internal code will eventually provide such functionality,
that's fine, but even then, why close the door on other possible extensions?

The proposal would both a) provide more UI flexibility and b) free up Emacs
development resources. The concept is no different from that of hooks
generally.

Customize needs hooks (of some kind) for two reasons: 1) Customize is
difficult to customize (convoluted widgetry), and 2) UI code is specialized:
it can be type-specific and field-specific (domain-specific). #2 implies
multiple UI interactions - different ones for different fields. (Perhaps #1
can be fixed; #2 is a fixture.)

Customize has existed for quite a while, and it has not evolved
significantly, so far. (Yes, I know that there have been improvements, but
the basic UI interaction is the same.) Why? Lack of need? Lack of initiative
to tackle the internal widgetry? General lack of resources? Lack of
priority? I don't know why, but I believe that significant progress could be
made easily by making Customize into an open framework that mini,
field-level UIs could plug into.

As you recognized (for color, at least), specifying values can involve
specialized user-input interaction. Why wait for Emacs to provide this for
various field types (color is only one example), and why limit the
possibilities to those that are provided by the Emacs distribution? Why not
open things up to any Emacs-Lisp code, and then let Emacs/FSF pick the best
candidates with papers for subsequent inclusion as the official, default
behavior?

The Emacs code is already open, of course, but the Customize UI is not
easily extendable (widget wizards to the contrary). The proposal was just to
make it easy to plug in mini-UI extensions.

The mechanism proposed is simple: provide a hook on each value field (or
possibly only to selected fields, according to their type). If the hook is
defined for a given field, then the field becomes active as a button. If the
button is clicked, the hook function is passed the current value (if any) of
the field and the defcustom info (type etc.). Via user interaction (or
whatever), the hook function can set/modify the value appropriately. Some
hook functions might not even change the value; they might provide only
analysis or browsing functionality for values of the particular domain
(field).

Think of a complex Customize field - `default-frame-alist', for instance.
Someone might write a field-editor for frame-parameter alists that is really
great, taking into account frame-parameter specifics, showing the possible
effects of changing particular frame parameters, and so on: direct
manipulation or simulation. If a Customize field hook were available, then
someone might be encouraged to write such a mini UI - it's a bite-size task
waiting to be tackled, and the result would be a useful plug-in to
Customize. If, that is, Customize could be easily plugged into.

Unless I'm mistaken, implementing this functionality would not be difficult,
and the payback would be instant flexibility in customizing Customize.