RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

I didn't think that we wanted to get into such discussions at this time. I
was intending to bring up this question only after the release.

But as long as people are discussing it, maybe we can decide to look into
the _question_ a little, to understand the current design better, without
going any further now.

I know that I don't understand the rationale behind this separation
inside/outside customize, and if I did I might be able to stop thinking
about trying to "improve" on it ;-). IOW, I really don't understand it, and
I really want to.

Why? Because if such a distinction were not really needed, then I think it
would be clearer for users to just have any change (regardless of where/how)
be treated as "setting" the user option.

    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.

Yes, it's unclear to me. Or, rather, it seems clear to me, but I think I
must be misunderstanding it, because I don't see the problem.

Does this action sequence correspond to what you mean?

1. Put (setq baud-rate 28400) in an otherwise empty .emacs.
2. Start emacs and customize baud-rate. The value shows as 28400 "changed
outside". Change it to 56000 and save it.

The setq appears before the custom-set-variable in your .emacs, so nothing
is overwritten (that I can see). If you restart emacs and customize
baud-rate, the value is 56000 "set and saved". Is there a pb I'm missing
here?

Perhaps you meant executing a setq _after_ the custom-set-variable (e.g. in
a library you load after the .emacs is loaded). If so:

1. Move the setq after the custom-set-variable in your .emacs.
2. Restart emacs and customize baud-rate. The value shows as 28400 "changed
outside".
3. Click "reset to saved". The value is 56000 "set and saved".

Something has changed the value after you loaded the saved value, but I
still don't see any problem. The customize state reflects that perfectly.

Of course, that is with the current system. You are saying that there
_would_ be a problem _if_ we treated "changed outside customize" as simply
"set". I don't understand how that would make any difference in this
scenario (action sequence above), besides indicating "set" to the user
instead of "changed outside customize" (which I think would be preferable).

So I'm guessing that I have misunderstood you. If the action sequence above
is not what you meant, what is?

Thanks,

  Drew