RE: customize-apropos

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

    Variables should not be included in the customize-apropos output
    just because their docstring starts with a `*'.  If a variable
    should appear in a customization buffer, one should define it
    with defcustom.

    The patch below fixes these two problems.  If people absolutely want
    to list non-defcustomed variables in the Custom buffer, they still can
    after my patch, by giving customize-apropos a numeric argument.

Your doc-string changes correctly reflect the current prefix-arg behavior -
the arg distinguishes customizable variables from other variables. However,
wouldn't it also be useful to be able to distinguish all user variables
(options) - whether customizable or not - from internal variables?

We have 3 sets of vars:

1. customizable user options - defined with defcustom.

2. non-customizable user options - defined with defvar, with * as first
doc-string char.

3. internal variables - defined with defvar, with no * starting doc string

The prefix arg currently distinguishes #1 from (#2 union #3). That can be
useful, but it can also be useful to distinguish variables designed to be
changed by users from those intended to be used internally: (#1 union #2) vs
#3.

I agree that customize-* commands should show customize stuff by default and
extra stuff, if at all, via prefix arg. But I think that a user will often
be more interested in seeing all user options than all variables, so some
means of showing #1 union #2 would be good to have.