RE: customize-apropos

[Drew Adams]

       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?

    Yes, but is it useful to have them in a Custom buffer?

    M-x apropos-variable will show all (loaded) user-options (defined with
    defcustom or docstring starting with a `*') and with a numeric arg it
    shows all variables.  Of course, it will not show them in a
    Custom buffer.

I see your point, I think. But wouldn't it be at least as useful to be able
to show all user options (i.e., including those that are not customizable)
in a Custom buffer as it is to show _all_ variables in a Custom buffer
(i.e., including those that a user should not change)? IOW, your argument is
really an argument for not showing anything in a Custom buffer that is not
customizable. That might be reasonable, but it is not the current policy.

If we keep the current policy of showing stuff that cannot be customized,
then it would also be good to clearly indicate when a user option cannot be
customized and when a variable is internal and should not be changed. That
is, clearly distinguish the three classes in a Custom buffer. I believe
that, currently, user-settable user options that are not customizable are
indistinguisable from internal variables in a Custom buffer.

Instead of saying just "NO CUSTOMIZATION DATA; you should not see this"
(which is what I see, in a CVS snapshot from June), a user option should be
labeled as such, with, for example, a message/label such as "You cannot
customize this option, but you can set it with command `set-variable'. That
might be somewhat confusing, but it is more helpful than what is displayed
currently.