RE: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

["Drew Adams" <drew.adams@oracle.com>]

Resending.

The basic idea is to (1) let Customize use completion where possible and (2)
improve completion possibilities for `customize-set-value' and
`customize-set-variable'.

> From: Drew Adams Sent: Tuesday, November 06, 2007 2:46 PM
>
> Here are some proposals for discussion:
>
> 1. Rename `customize-set-value' to `set-option', and
>    `customize-set-variable' to `set-option-default' (or
>    add aliases). Users will find these names easier.
>    These commands provide much better interaction
>    for reading the new value than does the current
>    `set-variable'. Their interaction subsumes that of
>    `set-variable', which uses only property
>    `variable-interactive'.
>
> 2. Rewrite `set-variable' to set any variable, not just an
>    option, and when the variable is an option then have
>    the code do what `customize-set-value' does. That is,
>    provide better value input interaction, when possible.
>
> 3. `customize-set-(value|variable)' needs some improvement.
>    Here are some things I notice:
>
> a. `choice' for a list of `const' is good - it provides
>    completion, which is very handy - a great improvement
>    over what is available in Customize, IMO.  However,
>    there is no indication in the prompt that completion
>    is (sometimes) available. And when completion is
>    available, the default value should be the current
>    value of the option, for possible editing. Currently,
>    there is no default value.
>
> b. `choice' that includes a non-`const' choice, in
>    addition to `const' choices: the types of the
>    non-`const' choices apparently govern what happens:
>
>  - If the non-`const' choice types don't provide for
>    completion, then no completion is available for the
>    `choice' at all. It would be better to have non-strict
>    completion and allow for the value that doesn't match
>    any `const' to be read according to its type. If possible.
>
>  - And, if the non-`const' choices also provide for
>    completion, then it should be possible to combine them
>    with the `const' values into a general completion. E.g.
>    a `choice' of a `function' or (const :tag "None" nil)
>    currently completes only against function names -
>    neither "None" nor nil are allowed as completion
>    candidates. Why not just add "None" to the list of
>    candidates?
>
> c. `repeat' seems to read a sexp and evaluate to obtain
>    the complete list - the complete value. This is a
>    cop-out and is not very useful. It would be better to
>    repeatedly read values corresponding to the list
>    elements, and then combine them to get the overall
>    value. For example `repeat' of `sexp' should
>    repeatedly read a sexp (until, say, empty RET) and
>    return the list of sexprs that were read. And I don't
>    see why the command should `eval' at all for `repeat'
>    - why wouldn't it just read, like it does for the
>    other types? And the user has no feedback as to what
>    is expected to be input (beyond "[repeat]" in the
>    prompt) - nothing tells him to input a sexp that will
>    be evalled to produce the overall list value. (And
>    end users should not need to think in such terms, anyway.)
>
> c. (choice (const :tag "None" nil) regexp) reads a
>    regexp string, but the default is "", not nil, which
>    doesn't seem right. And if you type `nil' or `None',
>    then the literal string "nil" or "None" is interpreted
>    as a regexp. Again, it would be better to allow lax
>    completion with sole candidate "None" and allow a
>    regexp string value as well.
>
> d. For type `color', lax completion should be available,
>    choosing from color names but also allowing input of a
>    #RRRGGBBB hex string.
>
> #3 is the most important of these suggestions. I don't
> have time to work on this much myself, but I can
> contribute a little time if someone else lead on this.
> What's really needed is someone knowledgeable in custom
> and widgets (ugh!).
>
> I hope that people will not argue that users should not
> use `customize-set-value' and `customize-set-variable',
> that they should preferably use Customize. I think both
> have their advantages, and these commands should be
> improved to make them viable alternatives. I also think
> that Customize itself could be improved to allow for
> completion where appropriate.
>
> WDOT?