RE: Changed outside --> set, in Customize UI

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

    > If, today, most "changes outside customize" occur
    > systematically, that is
    > because most represent _bugs_: libraries that are diddling
    > user options when they shouldn't.

    No, it's because the same code is executed at most startup.
    After all, your .emacs doesn't change much from one
    invocation to the next and you tend to
    use the same major modes from one invocation to the next, so
    the same code is triggered.

How much of this is caused directly by stuff in your .emacs and how much is
caused by stuff your .emacs loads? How many of the latter changes are really
_appropriate_ for libraries to make? That is, how much changing of user
options by libraries that you load each day is appropriate?

I don't know, but I suspect that most current changes of user options by
libraries represent bugs. And, given the discussion in this thread, I'm
hopeful that number will be reduced.

    > In the future, I expect that most such outside changes will be made by
    > users using other ways than Customize (extensions of Customize,
    > essentially) to change values.  Users will set options in
    various ways and
    > they will see that "Set" status correctly reflected in Customize.

    Then you're not talking about removing the distinction but
    about eradicating
    the cases where "changed outside customize" occurs.

I'm not interested in eradicating all the cases where "changed outside"
occurs. From the beginning, I've been interested in eradicating
_inappropriate_ changes of user options - as well as removing the
outside/inside distinction (in the UI). A user using a command to change a
face color is setting that user option - the change is both outside
customize and appropriate.

Currently, I suspect that most "outside changes" are inappropriate. I expect
the number of occurrences of appropriate (that is, user-intended) outside
changes to grow, both relative to the number of inappropriate such changes
and absolutely (due to Customize extensions that help users change options
"outside" Customize).

Setting user options, in whatever way, should be done by users, but users
should be able to use any means to do that.

    >     And even if it does show up, taking a look at the customize
    >     buffer when you see the problem will tell you "changed
    >     outside customize" warning you of the problem.
    >     What is the problem you are trying to solve, really? I.e. in
    >     what way is the message "changed outside customize" a problem?

    > Come on, you can't have it both ways. Either "changed outside
    > customize" is valuable because it is effective in warning
    > users about disastrous problems, or it is harmless (might not
    > help but doesn't hurt), has no effect, and
    > means nothing. Which do you want to claim?

    Notice I asked "in what way is the message `changed outside customize'
    a problem", which is not the same as "in what way is a situation denoted
    by `changed outside customize' a problem".
    Don't shoot the messenger.

I'm not. We're both talking about the message, not the messenger. The claim
was made that the message is invaluable in finding bugs and in warning
users. And I interpreted your last question ("what's the harm?",
essentially) as suggesting that the message is really not important, that it
is harmless. Is the message an important warning, or is it something
harmless that can be ignored?

    > IOW, turn your question around: In what way is using Set instead of
    > Changed Outside Customize a problem?

    Because it hides the fact that Custom has detected a potential problem.

The net is too wide. We don't want to scream "Wolf!" for all outside
changes. We only want to warn about identified problems (until we can fix
them).

    Do you want to solve the problem or do you want to put your
    head in the sand
    by removing the message warning you of the problem?

The warning is not going to solve the problem, which is a set of bugs that
need to be fixed. I already seconded Luc's suggestion of creating a _real_
warning until the bugs are fixed, but I also mentioned that it makes sense
to target such a message to those cases that we know are problematic, rather
than painting all outside changes with the same broad brush. We want people
to pay attention when we cry "Wolf!".