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

[Drew Adams]

> >> 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.
>
> Agree. I have a hard time remember which is which of ..-set-value and
> ..-set-variable.
>
> BTW, would it be good if set-option-default had a final question whether
> to save the new value for future sessions?

I'm generally against adding questions like that. If something like that is
needed, I usually prefer to do it only upon explicit user demand - e.g. via
prefix arg. And there are already commands for saving customizations, so I
really don't see the need to add that here.

> >>    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'.
>
> What is the reason for keeping the current version of set-variable?

For me, none.  AFAICT, `customize-set-value' subsumes it.

But I think it's very important to rename `customize-set-*'. When you want
to set the value of a variable, you aren't necessarily thinking of
"customizing" - especially since this is normally used outside a Customize
buffer.

In fact, it took me a long time to discover that `customize-set-*' did
everything I would use `set-variable' for.

The Emacs manual, BTW, does not even mention `customize-set-value' or
`customize-set-variable'. In node Examining and Setting Variables, it says
to use `set-variable' to set a user option: "The most convenient way to set
a specific user option variable is with `M-x set-variable'.". And node Emacs
Server also explicitly advises you to use `set-variable'.

I'm guessing that the manual does not mention these commands because Emacs
developers don't use them (and vice versa). That would mean that I'm not
alone in having continued to use `set-variable' long past its prime. Or
perhaps whoever introduced `customize-set-*' didn't care much about them or
about the manual - dunno.

Knowing that these commands exist is important. If you happen, instead, to
use `set-variable' for a defcustom, and there is no explicit
`variable-interactive' property, then the custom type is not even used to
read the value - it is used only to check that it is of the right type
(IIUC). IOW, `set-variable' is strictly not as good as `customize-set-value'
for defcustoms, and it is equivalent to it for defvars with a
`variable-interactive' property.

> >> 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.
>
> Sounds good.
>
> >> 3. `customize-set-(value|variable)' needs some improvement.
> >>    Here are some things I notice:
>
> I am not sure it is worth the effort to allow completion directly for
> more complicated variables.

Well, that's the main suggestion I'm making - I think completion is very
useful here. Customize is nice, especially for newbies, but with completion
you can move much quicker.

And as I also suggested (and you agree), Customize itself should let you
take advantage of completion. The current dialog is rudimentary without a
mouse. `RET' on `Value Menu' shows you a menu with numbered items and you
must read the items and then choose the right number. Completion, by
contrast, is a flexible and powerful dialog interaction. You need not
mentally map item number to item - just type to match. Completion is of
course even more useful if other kinds of completion matching are also
available (e.g. substring, Ido, Icicles).

[BTW, the `RET' menu is in fact broken if `pop-up-frames' is non-nil,
because the dialog leaves the `widget-choose' menu displayed (as a separate
frame) after you hit one of the menu-item numbers - it is never deleted.]

`customize-set-*' already provides some completion, but in only a limited
way. It is a good command, but some of the existing dialog is IMO a bit of a
cop-out. It looks as if someone just didn't have time to finish the job
(nothing wrong with that), which might also explain the incomplete state of
the manual. The treatment of `repeat' is a case in point - to me, that even
seems like a bug (why `eval' the user's input?). In any case, things could
be a lot better if some more effort were expended to provide completion
where possible. I hope someone will be interested in my suggestions
(previous mail).

> Why not use the custom buffer in such cases
> (and of course allow good completion there)? Maybe set-option(-default)
> could suggest/ask about that in those cases? Or maybe switch to the
> custom buffer then? (If that is not too confusing.)

No. The whole point is to have a quick and powerful command that you can use
*outside* Customize. There are already commands to use Customize to
customize things.