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

[Drew Adams]

    I [RMS] said:   
        To avoid confusion.  In general, it is a good idea to separate
        the values that users set from the values that programs set.
   
    You [Drew] responded with a misunderstanding:  
        Pick a level of unity for the "Set" (vs "changed-outside") club:
        1. Set inside Customize.
        2. #1 + `set-variable' used interactively.
        3. #2 + any command called interactively that has as 
           purpose to change the value. 
        4. #3 + any interactive command, used interactively or not.
        5. #4 + any function or sexpr executed interactively (`M-:').
        6. #5 + any function or sexpr called by any function or sexpr
           in #5. 
        7. #6 + explicitly loading any library (interactively).
        8. #7 + loading any library in your custom file (.emacs).
        9. #8 + loading any library, even indirectly.
    
    You're trying to distinguish cases based on MECHANISMS used to set
    the variable.  That's not the kind of distinction we are making.
    We are not talking about how it's done.  The distinction here is
    who decides to set this particular variable.  Does a certain Lisp
    program decide, or does the user decide.

Yes. I argued that _none_ of the above mechanisms is an adequate
indicator of "who decides to set this particular variable."  We agree,
I think, that _no_ mechanism is ultimately adequate to that task. The
question of who is deciding a particular change can only truly be
answered by the user.

But we have no choice: _If_ we try to determine _by code_ who is doing
the deciding, then we need some objective criterion (we don't want to
ask the user, about each change that is made, "Did you intend
that?"). IOW, we must look at how a change is made _if_ we wish to
maintain an outside/inside distinction - we must examine the setting
mechanisms. And the current scheme does indeed make the determination
based on mechanism (clicking Set inside C. vs everything else).

    The question you posed does not require an answer.

This is the two-part question I posed: "Is there is a good
inside/outside boundary to choose? Which kinds of changes should we
allow inside the "Set" club?" The placement (and the need) of this
boundary has been the question from the beginning. It requires an
answer _if_ people are arguing for maintaining an inside/outside
distinction: How is the boundary to be defined?

My answers to the two-part question are (1) "No, there is no good
boundary" and (2) "All changes should be considered to 'set'
options". I argued that none of the mechanisms I listed is adequate to
the task: All user-option changes, no matter how they are made, should
be admitted to the Customize club. The inside/outside distinction is
not a useful one to maintain.

If my list of "mechanisms" is not complete or is off the mark, if
there is an adequate criterion to distinguish inside changes from
outside changes (whether "mechanism" or not), let's hear it.

I said in an earlier message, and you seemingly agreed: 

        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.

You seem to agree in general, but you also seem to suggest that the
particular program code could be examined to determine intention - if
it offers the user a choice, then presumably the user is in charge; if
it does not, then the _program is deciding_. Is that what you mean?

If so, then I disagree. Even a program that offers no choice can be
run or not, according to user choice. That particular mechanistic
criterion (program offers a choice or not) is no better than
interactive vs non-interactive. Again, user intention "is not a
criterion we can test by program."

I proposed that we make no inside/outside distinction, that we regard
all changes to user options as "setting" them. What to do, then, about
programs and libraries that set options? I pointed out that some are
_designed_ to set options (and when a user runs them, the user is
choosing to set those options), and some (multi-user libraries, in
particular) should not set options (if they do so now, they must be
corrected).

I argued that the only exception to considering all option changes as
"setting" the options is the startup sequence:

    This difference in library kind (purpose) can be reflected in the
    treatment by Customize. It is normal for .emacs and personal
    libraries loaded at startup to set user options. Those option
    values should not then be considered "changed outside" or even
    "set" in Customize. They should be considered as the normal,
    usual, baseline values for that user.  That is, they should
    constitute the "unchanged" zeros of the Customize world.

This "personal option calibration" (using startup values as baseline
values) is simply a convenience, to let users distinguish any changes
that are made after their persistent preferences are loaded (where
"persistent preferences" includes values set by libraries loaded at
startup). It has nothing to do with the changed inside/outside
distinction.

In my proposal, there is no inside/outside distinction - the only
states are `saved', `standard', and `set'. `Standard' is defined by
defcustom; `saved' (or `unchanged') is defined by whatever values are
established during startup; `set' results from _any_ option change
made after startup (except change to `standard').

All code that changes user options "sets" them, but if code is run
during startup we would mark the values as "unchanged", as a
convenience. The _same_ code can thus result in Customize considering
the library's settings as "unchanged" (if run during startup) or "set"
(if run after startup). In no case would any option be marked in
Customize as "changed outside".

It is thus not the character of the code that makes a difference, but
what the user does with it: If a "library" of user settings (setq this
and that) is loaded during startup, the user intends those settings as
part of his baseline setup ("unchanged", aka "saved"). If the user
loads such a library after startup, the user intends its settings to
be regarded as changes ("set").

This convenience does mix together, under the category `saved' (or
`unchanged') 1) values that are saved by writing them in the custom
file with custom-set* with 2) values that are established during
startup by loaded libraries. All such baseline values are persistent:
restarting Emacs will reestablish them as the user's normal
settings. But their origin is different.

I think that combining (1) and (2) is a useful convenience - it is
better to see "unchanged" in Customize next to a value that is set by
some library during startup than it is to see "set" next to it. This
could be debated: some people might prefer to distinguish (1) from
(2). The idea is to let users see changes they make in their .emacs
and other personal libraries show up as their "unchanged" ("saved")
personal settings. We will of course need to fix the bugs we've
discussed, and get rid of any inappropriate setting of user options in
multi-user libraries (e.g. standard libraries), so that this
convenience actually reflects _persistent personal preferences_ and
not rogue option changes made by misbehaving libraries.

      [Luc] Referring to something set in .emacs as "Set for the
      current" session would be very confusing because things set in
      .emacs outside and inside the `custom-set-variables' form are
      set in the same session.

   [RMS] I agree.  Perhaps "set by .emacs" should be distinguished as
   a state.

We agree not to use "set" for startup settings. I proposed to use
"unchanged" (aka `saved'). I'm not convinced that it is useful to
distinguish custom-set* settings from .emacs settings in this regard,
but I'm open to being convinced that "set by .emacs" (startup) should
be distinguished as a separate state. Reasons?

Things set "in .emacs outside and inside the `custom-set-variables'
form are set in the same session"; and they are both set during
startup; and they are both persistent ("saved"), although they are not
saved in the same place or reestablished in the same way.

I'm not sure whether we disagree, since you apparently agree with the
"new tack" points (except #10), which in fact reflect what I've
written above. And what do others think?