RE: Eliminating "changed in Emacs outside of Customize"

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

    >     Was this unclear:
    >       If you .emacs, or some third party code you
    >       activate from ".emacs", contains "(setq foo 42)" and
    you change and
    >       save "foo" from customize, you changes to the variable through
    >       customize will be overwritten next time you start Emacs.

    It's crystal clear to me, but let me try to rephrase it, to see
    if it helps other people:

       - Let's imagine user Helen has had a (setq-default
         fill-column 42) in her
         .emacs (or maybe it's in some package that she doesn't
         even remember
         she's loading from a .emacs).
       - Now let's imagine that Helen notices that her fill-column
         is too small
         and she wants to set it to something else, like 70.
       - She does M-x customize-variable RET fill-column RET, then
         changes the
         value, then saves.
       - When she restarts, fill-column is 42 again.
       - Since she's not arrogant, she figures she must have made a
         mistake so
         she goes through the customize-variable thingy again.
       - When she restarts, fill-column is still stuck at 42.
       - Then comes M-x report-emacs-bug.

    Of course the above problem will only happen if the (setq-default
    fill-column 42) happens to be executed after Helen's
    custom-set-variables
    (e.g. in a mode-hook or in one of the many poorly written major
    modes that
    happily mess up global variables).

Right. I believe that's exactly the behavior I described, as well.

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?

If so, are we in fact getting such bug reports from Helen? If so, then maybe
something could be done to make the behavior clearer to her.

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

 - Drew