RE: customize-apropos

[Drew Adams]

    I do not believe that the numeric arg is really useful (it is just a
    confusing alternative to apropos-variable), but it does no real harm
    either.  Unless somebody uses it for no other reason that they do not
    know about apropos-variable.  That is why I proposed my patch pointing
    out in the docstrings that in most cases using `apropos-variable' is
    more useful than using the numeric arg to `customize-apropos'.

One big difference between `customize-apropos-options' and
`apropos-variable' is that the former puts you in a Custom buffer, where you
can customize options and easily navigate (browse). Even if someone wants to
_see_ all matching variables, (s)he might still want to browse or customize
some customizable user options. Plus, Custom is intended to present a more
"user-friendly" face for option names, values, and value descriptions (I
won't go to the death defending the current implementation of that feature,
however).

So, I cannot agree that "in most cases using `apropos-variable' is more
useful." It is, in most use cases, _less_ useful. Everything that
`apropos-variable' gives you, `customize-apropos-options' (with prefix arg)
gives you too. And the latter gives you more, and in a more digestible
format (that's the intention, anyway).

My point was not to get rid of the C-u behavior - it was to get rid of it
_IF_ the only acceptable (to you and RMS) alternative is an end-user
description that is confusing or frightening. Fixing the language is the
other alternative.

I said: "Experts don't need this (C-u) any more than regular users."

Equivalent: Regular users need this (C-u) just as much as expert users.
Casting the C-u behavior as an expert-user feature is wrong, IMO.

The alternatives I proposed are: get rid of the C-u behavior _OR_ fix the
descriptions of non-defcustom variables, so they don't confuse and frighten.

Richard's latest proposal of wording is this:

  "NO CUSTOMIZATION DATA; set this only if you know what you are doing."

I feel that "if you know what you are doing" is confusing, unhelpful, and
frightening. Might as well say "Don't set this!" - those who do know what
they're doing will presumably know enough to ignore that admonition.

_I_ don't know what "if you know what you are doing" means (how does one
know whether one knows? what's the secret key?), so I must assume that I
don't know what I'm doing. Fair enough, I won't set the option in Custom -
but I won't learn anything about why not or about how I might legitimately
set it (`set-variable').

I will get the (false) impression that setting that option is something only
for THOSE WHO KNOW (and know that they know). And I will have no idea how to
become a member of those-who-know. I will come away thinking that Emacs is
indeed mysterious and Custom is not something for the faint of heart. I will
wonder why, if people should not set those options, setting them was
presented as a possibility (instead of simply getting rid of the State
button or editable Value field). I'll begin to wonder about a lot of things
Custom, in fact.

If we cannot distinguish the problematic (bug) cases (which Luc listed) and
the internal-variable cases from the non-defcustom user-option cases (`*' in
doc string), then I guess we are stuck with language such as that Richard
proposed.

But a better solution would be to distinguish those cases, and tell people,
in the user-option case, that they can use `set-variable' - nothing to fear
here, nothing esoteric.  For a non-defcustom user option, we could even
provide a link that called `set-variable' directly. IOW, it's better to
reserve the less-informative, more frightening language for the bug and
internal-variable cases. Better still would be to remove the State button
from variables whose value should not be changed in Custom - experts have
other ways to change them.

And, as I mentioned near the beginning of this thread, it is at least as
useful to be able to show all _user options_ (no internal variables) as it
is to show all variables (current C-u behavior). If we offered that (e.g.
via C-u `customize-apropos-options' or via `customize-apropos-variables'),
and we got rid of some of the bug cases, and we distinguished the
`set-variable' user options, then we would have no scary, abracadabra,
secret-cult language at all.

If this is too much to ask before the release, consider this a prelude to
Customize discussions to come after the release. That beast sorely needs to
be tamed.