RE: customize-apropos

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

       But current policy also shows non-customizable variables if you use
       the numeric arg.

    I have already told you: this is not a policy, but a way to _override_
    a policy.  The _default_ behavior (no numeric arg) is the policy.  (If
    not, Richard can correct me.)

Well, excuse me, but it is I who first used the term "current policy" in
this context - what _I_ meant was "current behavior". Whether or not you or
Richard considers the current numeric-argument behavior to be "the policy"
is irrelevant to my meaning. The context of my use of the term "current
policy" made it clear that I was referring to the numeric-argument behavior.

    I kept the numeric arg just so if
    anybody, for any reason whatsoever, had gotten used to it, they would
    still be able to use it (although I seriously doubt that this applies
    to a lot of people).  That numeric argument is an *obscure unimportant
    detail*.  Let us just stop worrying about it.

Why you kept it is irrelevant at this point also - if the behavior exists,
people can use it, and some will. _You_ went to the trouble of changing the
doc strings to clarify this "*obscure unimportant detail*". Why did you
bother? I, for one, am glad you did.

I return to my original question:

  "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)?

  If we keep the current [behavior] of showing stuff that cannot be
  customized, then it would also be good to clearly indicate when a
  user option [is not a defcustom option] and when a variable is
  internal and should not be changed. That is, clearly distinguish
  the three classes in a Custom buffer.

For "not customizable" and "cannot be customized", read "not defined with
defcustom".