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

[Richard Stallman <rms@gnu.org>]

Your summary is very useful, but there are some points I don't follow
or disagree with.

    One problem mentioned is that trying to save a "changed-outside"
    option might not "work": some library you load might change the saved
    value to something different after you restart. Well, _setting_ an
    option in Customize and then saving it might not work either - for
    exactly the same reason.

I don't understand the argument there.  What is the secons scenario?

	When changing a defcustomed variable from a function, that
	function should be interactively called by the user

    Why?

To avoid confusion.  In general, it is a good idea to separate
the values that users set from the values that programs set.

    The idea behind limiting Customize admission to only interactive
    functions I think hints at the proper criterion, but it does not hit
    it square on. The idea of user Helen "setting" an option really comes
    down to this: user _intention_. That is not a criterion we can test by
    program, but it is the only reasonable criterion, IMO.

I agree; I think that's exactly what it means to me.  Users set
variables by running programs.  The difference is that in one case the
intention to set variable X is embodied in the program code; in the
other, the progranm could set any variable, but the user chooses to
set X.

    A user option is a user option, and it should be totally under _user_
    control. Proper functioning of a user hook, for instance, should not
    depend on any properties of the hook value, such as additional hook
    functions, that the user does not control or is not aware of. If that
    means that we have to split lots of user hooks in two (user; system)
    or otherwise bend over backward to avoid stepping on user settings,
    then so be it - we'll just have to bite the bullet.

That would  be a big price to  pay.  Even if the  other alternative is
imperfect, it may still be better.

    It would be useful to separate these two issues even if the problems
    raised did not exist already and were not, therefore, unrelated to the
    proposed UI change.

Maybe-- but we shouldn't change any of these things now, so maybe
we can just as well consider them both together as part of a redesign
of the Custom user interface.