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

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

>     Since `set-variable' was also intended to change the values of user
>     options with the leading * in their docstrings, I think a new command
>     `set-option' should be added with the body of current `set-variable',
>     and `set-variable' should allow modifying any variable.
>
> I don't consider that a good reason for such a change.
> If I see some additional experienced users who want this as a convenience,
> then I will agree to the change.

Those quotes provide some context, but this is really about
`customize-set-value' and `customize-set-variable'. 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 leads
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?