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

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?

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

[Richard Stallman]

     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.

I see no need to worry about hooks for calling this.
Once someone has implemented a nice way to specify a color,
we can make things call it.

    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.

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.

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

[Richard Stallman]

    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?

There's no need to spend our time on it.  People playing with such
interfaces easily redefine a function to make it call their code.
We do not need an elegant mechanism.  I don't want to spend time
thinking about it.