RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    The "Changed outside customize" has been a great help for me to catch
    those hooks, setq's and poorly written major modes, and I think Emacs
    has improved because of it, by fixing the modes and rethinking the
    hooks.

    I can see there is a lot of followup mails.  I don't have time for
    either discussion or design, so I'll skip them unread.

    If someone have specific questions, mail them to me directly.

I still have the specific question of _what the problem is_ with the
scenario that you and Stefan (and I) described: a setq (in .emacs or a
library) executed after custom-set-variables. Yes, a setq changes the
current value so that it is no longer the `saved-value' - but so what?

And, more importantly, what that pb has to do with a proposal to eliminate
the distinction between "changed outside" and "set" in favor of only "set".
The behavior in the scenario seems to me to be the _same_, regardless of
whether such a proposal were adopted. IOW, the scenario doesn't seem to show
the reason to maintain the distinction.

I know you're busy, but I think that only you can help with this specific
question. Help us understand what the pb is.

Here's what I wrote before on this (which you perhaps missed):

          Was this unclear:
              If you .emacs, or some third party code you...

    What is not at all clear (to me) is what this has to do with
    the supposed need to distinguish, for the user, a value that is
    changed using a customize buffer from a value that is changed
    otherwise. The original question was that: "What would be wrong
    with treating, in the Customize UI, outside changes the same as
    inside changes?"

    IOW, nothing in the above description (Stefan's or Per's) makes
    any mention of replacing "changed outside" by "set" in the
    Customize UI. The above description holds perfectly in today's
    vanilla Emacs, does it not? ...

    Beyond that, what does this have to do with the question: "What
    would be wrong with treating outside changes the same as inside
    changes - in the Customize UI?"

WRT the value of such a distinction in helping us identify "hooks, setq's
and poorly written major modes" that don't play by the rules: I've found (by
experiment) that removing the distinction changed-outside/set actually makes
such faulty library codings _more visible_, not less. If every change is
considered to "set" the option, then querying with customize-customize picks
up all such faulty changes (along with any user changes made inside
customize).

Yes, the same info is available today via customize-rogue. My point is that
erasing the distinction (in the UI, for users) doesn't hamper our ability to
find such rogue library coding. And in fact it can make it more visible to
more users. That visibility could help us by inviting more bug reports on
faulty coding in libraries that we might not check otherwise.

So, the main thing that it would be a great help to clear up is 1) just what
is the pb with the scenario that you outlined, and 2) what does that
scenario (and pb) have to do with possibly erasing the distinction between
changed-outside and set.

Thanks,

   Drew