RE: customize-apropos

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

       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.

    I believe that it _is_ the current policy not to show any variable in
    a Custom buffer that is not defined with defcustom.  That is exactly
    why I installed my patch to customize-apropos.  The numeric argument
    is just a way for a super-sophisticated user to override that policy.
    I personally do not care about that numeric argument.  I just kept it
    because it was there.  I would not have put it in myself.

Use of the numeric argument was precisely the point in question. Yes,
without the argument variables in Custom are customizable. But current
policy also shows non-customizable variables if you use the numeric arg.
That's the point under discussion - like it or not, that's the current
policy.

       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.

    No.  People should _really_ not see this, unless for some (strange)
    reason they very explicitly asked for it.  The message is intended for
    two kinds of people: the average user and the person who wrote a
    defcustom and checks his work.  The "you should not see this" tells
    the average person to stay away from it and, if he saw it without
    doing anything unusual, file a bug report.  It tells the programmer
    that there is a bug in his defcustom.

What do you mean by "some (strange) reason"? If we allow the numeric-arg
behavior, then we allow non-customizable stuff to be shown - that's current
policy, strange or not. If we allow numeric-arg behavior, then we want to
inform people that they cannot (or should not - see below) customize it (in
Custom). I think we agree so far (?). Where we disagree, I think, is whether
we should tell people how they _can_ change such non-defcustom options. I
think we should mention `set-variable'; you do not.

    Your suggested replacement text is incorrect.  If you really know what
    you are doing, you _can_, up to a point, customize these variables in
    the Custom buffer.

I take your word for it (but tell me how; I'm curious). Change my use of
"cannot" to "should not" in that case: these are variables that we do not
want people to try to change using Customize, right? Do we agree that Custom
buffers are not _intended_ for changing non-customizable user variables
(sorry, I mean variables not defined with defcustom).

    Since some things will work and others not, I
    would definitely not recommend this for the average user.

Not recommend what? Trying to partially customize non-defcustom stuff? Or
using the numeric arg with customize-apropos to display non-defcustom vars?

    I also believe that the usefulness of this feature for advanced users is
    limited.  I have never used it except out of curiosity.

I'm not clear on which feature you're referring to. The numeric-arg feature?
If so, I have no problem with getting rid of it. But there should be some
way for users to get the list of all user variables (defcustom or not) - do
you want another command?

And it would be preferable for those user vars that are customizable to be
shown in a Custom-buffer context, for easy customization. Would you prefer a
separate command that did both of these things? 1) showed the matching
defcustom vars in a Custom buffer, 2) listed the matching non-defcustom vars
in a *Help* buffer, with their descriptions and an intro sentence saying
that you can change them with `set-variable'. I would prefer just using
Custom and putting the message about `set-variable' there, next to each non-
defcustom var.