Changed outside --> set, in Customize UI

Changed outside --> set, in Customize UI

[Drew Adams]

A lot has been written on the question of eliminating the distinction,
in the Customize UI, between "set" and "changed outside".

To summarize a bit:

I argued for removing this distinction.

Per and others said that keeping a distinction can be useful for
debugging. I replied that if so, then an internal distinction should
be enough for that purpose; we should still eliminate the distinction
in the UI.

Stefan and others pointed out that if a saved user option is changed
afterward by Lisp code (including code in .emacs), this can be
confusing.

Along the same lines, Luc and others pointed out non-trivial problems
with libraries that modify user-option lists such as hooks. One of
these problems, for example, is that libraries sometimes make changes
that essentially implement `standard' values, but are not recognized
by Customize as doing that. 

A user cannot then reset subsequent changes, to get back to the
`standard' state the library provided. And there is no easy way for a
user to add hook functions to pre-supplied (=`standard') functions in
a hook and later be able to take advantage of bug fixes that might
change what the `standard' component is.  Instead of including
explicit standard functions in the hook, the intention is really to
have the equivalent of ,@(current-std-hook-fns) in the hook.

Some of the problems raised are serious, and their investigation and
possible ways to fix them have opened an interesting discussion.
However: 1) all of the problems raised exist already today, and 2)
they are unrelated to the UI proposal.

Some people feel that the "changed outside" indication in the UI
serves a purpose by in some way warning users of these potential
problems. I maintain that it does _not_ act as such a warning and does
_not_ help in any way with these problems.

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. If users think they can rely on _not_ seeing
a changed-outside "warning", then they are misled. If you see a
changed-outside warning, beware; if you don't see such a warning,
beware. This is a distinction without a distinction.

There can also be lots of user-option changes made outside Customize
that are _not_ problematic. _Every_ change to a user option, besides a
user clicking Set in Customize, currently shows up with the
changed-outside "warning" - even benign changes. Instead of seeing a
warning in such cases, the user should simply see that the option has
been _set_ - because it has. A library might well set some user
options as an intended effect, the library being used in effect as an
extension to Customize, without any unpleasant side effects
necessarily occurring.

The same motivation for changing `set-variable' (post 21.4) so that
its effect is reflected in Customize as "set" instead of
"changed-outside" (ignoring the :set complication) is my motivation
for treating all other ways to change options the same way: make
things clearer and simpler for the Customize user. Customize should
play well with `set-variable'; it should do likewise with all other
user-option changes.

After all, what is special about `set-variable'? What about your new
command `my-super-face-morpher-and-tweaker', which changes face
parameters?  Why shouldn't it benefit from the same treatment in
Customize as `set-variable'? Your command effectively extends the
Customize UI, letting users change face parameters in a new, powerful,
and easy-to-use way. So, let's add your command to the Customize club.

But, where should we draw the line on admission to the club?
Interactive changes only, perhaps?

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

Why? And what is "interactive", anyway, in this context - does it mean
only `interactive-p'? A Lisp function or a library can define a
different `standard' value for any user option. Why shouldn't a Lisp
function or a library "set" an option value - or even a bunch of
values? If your _purpose_ in using the program or library is the same
as your purpose in using `set-variable' - to set some values for the
current session, then why should Customize consider such settings as
"rogue" (changed-outside) and throw up its hands?

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.

If something changes an option in a way that Helen is not aware of or
doesn't want, then that is _not_ Helen, the user, setting the option,
and that behavior will confuse her. If she uses <WHATEVER means> to
set an option _on purpose_, then that _is_ Helen setting the
option. Helen does not care, in principle, whether she uses Customize
or `my-super-face-morpher-and-tweaker'; she just wants to change her
settings and then (possibly) save them.

Only Helen can know her intentions. We cannot reasonably separate
user-option changes into changes that are "inside" and changes that
are "outside" her intentions - only Helen can do that. What we can do
is try to limit the number of functions and libraries that change user
options and make their behavior clear and obvious.

Claiming that any change to a user option should be reflected as "set"
in Customize does not of course mean that any arbitrary change is a
good change. It is neither necessarily bad nor necessarily good (nor
even benign) for Lisp code to modify a user option. It is bad for Lisp
code to diddle Helen's options without her knowledge, and it is very
bad for Lisp code to change her options in a way that prevents her
from returning to saved or standard values.

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.

A user option must be under user control. However, as a general rule,
user control _includes_ the ability to use functions and libraries,
and that includes using them to set options.

What about the use of the "changed outside" flag for those outside
changes that do represent real problems? Even there it is
inappropriate, for "changed outside" is insufficient to let anyone
know what the problem might be or what to do about it. Combining the
benign and helpful with the seriously problematic, "changed outside"
really means nothing useful to users as a "warning".

We can try to distinguish between 1) outside changes that can be seen
to represent bugs and lead to problematic behavior and 2) other
outside changes. We can then try to fix the problems. 

Until fixes are implemented, we could, as Luc suggested, display a
proper warning for the cases we can identify as problematic. We should
not, however, paint all outside changes with the same broad brush.
Bugs are bugs. It does not help to treat each outside change as a
possible bug by flagging it with a warning - quite the contrary, if we
want people to pay attention to such warnings.

Let's separate 1) the question of the _desirability of changing the
UI_ ("changed outside" -> "set") from 2) the how-to questions of
_problems that need fixing_.

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. The distinction here is user interface vs
implementation: Is "changed outside" really helpful in the UI? It is
all the more useful to separate these two discussions, since the
problems do exist independently of the UI question.

If we nevertheless suppose, for argument's sake, that "changed
outside" does in some way help users avoid some of the problems
raised, then a weaker form of the UI-change question can be
considered: _If_ problems like those discussed can be solved, is it
then a good idea to use only "set" for today's "set" plus today's
"changed outside"?

As to the desirability of the UI change (replacing "changed outside"
by "set"):

      > It is clearer for users without such a distinction.
    
    I rely heavily on the distinction. I cannot see what is "clear"
    about identifying two things that have not the slightest thing to
    do with each other.

Changing user options inside customize and changing them outside have
this to do with each other: they are both about _changing user
options_ (which is what users think customizing is all about). If a
distinction doesn't serve, then things are clearer without it.

It would be good to hear arguments as to why the UI distinction should
be kept. So far, all of the arguments have involved reference to
existing problems that are independent of the proposed UI change.

But even if there are no good arguments not to change, some people
might just prefer the UI as it is. At a minimum, this preference
could, well, itself be treated as a user preference, that is, a user
option. That might satisfy everyone. After all, if we maintain the
distinction internally anyway, then it should be trivial to optionally
maintain it or remove it in the UI. Of course, we might then argue
about which presentation should be the default one, but at least both
preferences would find a home.

At a minimum, then, I would argue for a user option to let users not
be bothered with the difference between changes inside and outside
Customize. I think that will be clearer for users without this
distinction; others think not. Why don't we let users choose
individually?

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

[Stefan Monnier]

> 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. If users think they can rely on _not_ seeing
> a changed-outside "warning", then they are misled. If you see a
> changed-outside warning, beware; if you don't see such a warning,
> beware. This is a distinction without a distinction.

Nice theory, but in practice there is a big difference, because in most
cases the "changes outside customize" either always take place or never take
place, so it's a rare occurrence when the problem you mention shows up.

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?


        Stefan

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

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> A user option must be under user control. However, as a general rule,
> user control _includes_ the ability to use functions and libraries,
> and that includes using them to set options.

Yes. I believe a lot of users like customizing with other tools than the
Easy Customization GUI. But I do believe that changing defcustom vars should
be done with custom-set-variables (or the like) in those tools. Is that a
problem?


This discussion has also made me wonder if we need some clear explicit rules
for this. It could look something like this:

1) defcustom vars should have a user part and a tools part (ie two variables
as suggested before). Only the user part is handled in Easy Customization
and saved etc. (Maybe the tools part should be shown too however.)

2) Packages that are not meant to do a saveable customization for the user
changes the tools part of this double variable.

3) Those packages that want to do a saveable customization change the user
part. This should be told in the description of the interactive functions
that can cause such changes.

4) The user part takes precedence over the tools part. (This means that
there must be a way to say "don't care about me" for the user part.)

The above rules are just meant for thought now of course.


> What about the use of the "changed outside" flag for those outside
> changes that do represent real problems? ...
> We can try to distinguish between 1) outside changes that can be seen
> to represent bugs and lead to problematic behavior and 2) other
> outside changes. We can then try to fix the problems.
>
> Until fixes are implemented, we could, as Luc suggested, display a
> proper warning for the cases we can identify as problematic.

I agree that it would be good, but should we not go the other way round?
Until we have understood that it is not problematic should we not assume
that it is?

Maybe some of these problems will disappear with the suggestions Richard had
for handling list defcustoms (splitting them in in a "user" and a
"tool/code" part before editing them in Easy Custom).

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

[Drew Adams]

    > 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. If users think they can rely on _not_ seeing
    > a changed-outside "warning", then they are misled. If you see a
    > changed-outside warning, beware; if you don't see such a warning,
    > beware. This is a distinction without a distinction.

    Nice theory, but in practice there is a big difference, because in most
    cases the "changes outside customize" either always take place
    or never take
    place, so it's a rare occurrence when the problem you mention shows up.

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

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.

Changes to user options should be _user_ changes, and, as such they will not
be systematic, no matter how they are made. When a user wants to make a
change systematic, Save (or Standard) is used.

    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?

I maintain that it is 1) confusing, 2) ineffective in preventing or dealing
with the problems mentioned, and 3) a meaningless distinction from Set. A
meaningless distinction is not harmless, because it confuses users. Occam
says, "Get rid of it."

Setting an option is setting an option, no matter how or where it is done.
And users should be the ones setting user options, so, yes, the bugs need to
be fixed.

Again - so far, I have seen no argument

    as to why the UI distinction should be kept. So far, all of the
    arguments have involved reference to existing problems that are
    independent of the proposed UI change.

IOW, turn your question around: In what way is using Set instead of Changed
Outside Customize a problem? How about an argument justifying the
distinction, to stave off Occam and his nasty razor?

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

[Stefan Monnier]

>     Nice theory, but in practice there is a big difference, because in
>     most cases the "changes outside customize" either always take place or
>     never take place, so it's a rare occurrence when the problem you
>     mention shows up.

> 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.

> 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.

>     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.

> 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.

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?


        Stefan

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

[Richard Stallman]

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.

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

[Luc Teirlinck]

Drew Adams wrote:

   How about an argument justifying the distinction, to stave off
   Occam and his nasty razor?

I gave several arguments.  The fact that you do not understand certain
arguments, or do not agree with them, does not mean that no arguments
were given.

   so, yes, the bugs need to be fixed.

But we can not hurry and try to fix all of them for 22, because that would
nearly guarantee that we would be introducing more bugs than we would fix.

   At a minimum, this preference could, well, itself be treated as a
   user preference, that is, a user option.

I do not believe that it would make sense to introduce an option for
one single release (or *maybe* two should 23 be released very soon
after 22).

After we change the Custom interface to get rid of the various bugs I
described, the user will probably not be able any more to even _try_
to undo an `add-hook' in his .emacs through Custom (which would not
work anyway).  He would see the added hook in the Custom buffer but it
would appear as being "untouchable".  He would have to remove the
`add-hook' from his .emacs.  That is the only way that works anyway.
The _illusion_ of being able to do it from the Custom buffer would no
longer be there. 

We might actually decide to do this not just for hooks and list-vars,
but for _all_ options.  If set in .emacs, make it appear
"untouchable".  If the user really wants to set it through Custom
instead, he can first erase the .emacs customization.  That is the
only solid way to proceed.  Even if the `custom-set-variables' form
occurs _after_ the setq and the setq thus _gets_ overridden, that setq
is bound to sooner or later confuse the user.

_Not_ for 22, however.  *Much* too late in the game.

Sincerely,

Luc.

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

[Luc Teirlinck]

>From my previous message:

   We might actually decide to do this not just for hooks and list-vars,
   but for _all_ options.  If set in .emacs, make it appear "untouchable".

Well maybe "unsavable".  We can worry about such stuff when we are no
longer in a feature freeze and somebody has the time to implement things.

Sincerely,

Luc.

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

[Luc Teirlinck]

>From my previous message:

   We might actually decide to do this not just for hooks and list-vars,
   but for _all_ options.  If set in .emacs, make it appear
   "untouchable".

As I already pointed out before that might not be the best idea, since
the user can still safely set the variable for the current session,
even though not save it.

Of course, we have the similar problem that if we make an entry set
with add-hook in .emacs untouchable, then the user can not undo it
for the current session any more either, even though this is feasible
and safe right now.

I believe that it is possible that we might still need "Set outside Custom"
after fixing the hooks-listvars bugs.  If you have set an option in
your .emacs ten years ago, you need some reminder that you actually
set it in your .emacs, or you might have forgotten it.  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.

Anyway, now is not the time to discuss such things.

Sincerely,

Luc.

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

[Drew Adams]

    > 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!".

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

[Drew Adams]

       How about an argument justifying the distinction, to stave off
       Occam and his nasty razor?

    I gave several arguments.

I meant arguments about the desirability in the UI of "outside" + "inside"
vs just changed". I haven't seen those arguments.

I saw problems pointed out that already exist today. They cannot, therefore,
be related to the proposed UI change, unless the problems are seen to be
exacerbated by the UI change. You did argue that the current warning serves
to protect from the pbs, which is a valid point (that I disagree with).

       so, yes, the bugs need to be fixed.

    But we can not hurry and try to fix all of them for 22, because
    that would nearly guarantee that we would be introducing more
    bugs than we would fix.

Agree 100%. And the proposed UI change "changed outside" -> "set" wouldn't
be for 22.1 either.

       At a minimum, this preference could, well, itself be treated as a
       user preference, that is, a user option.

    I do not believe that it would make sense to introduce an option for
    one single release (or *maybe* two should 23 be released very soon
    after 22).

Do you mean that if all the bugs are fixed you will no longer prefer
"outside" + "inside", that you will prefer just "changed" (set)? If so, then
there is no need (for you) for a user preference here. If not, then why
would this be limited to 1-2 releases?

    After we change the Custom interface to get rid of the various bugs I
    described, the user will probably not be able any more to even _try_
    to undo an `add-hook' in his .emacs through Custom (which would not
    work anyway).  He would see the added hook in the Custom buffer but it
    would appear as being "untouchable".  He would have to remove the
    `add-hook' from his .emacs.  That is the only way that works anyway.
    The _illusion_ of being able to do it from the Custom buffer would no
    longer be there.

Good (IIUC).

    ..._Not_ for 22, however.  *Much* too late in the game.

Agreed 100%.

We really need to devote some time to discussing possible changes in depth.
Customize has great potential, but it needs some work, too. It would be good
to get solid agreement (consensus) on what we want to do wrt the user
interface and wrt the implementation. Also, Per is a key player in the
Customize design and implementation, and he has no time to participate in
discussion now. Besides perhaps fixing some of the bugs, there is no reason
to hurry any changes to Customize; it's better to take our time and get it
right.

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

[Drew Adams]

Note: In this reply I also provide some of the reasons for the new
approach outlined in my separate mail, Subject: New tack for
Customize. See, for instance, the distinction below between different
types of library and how to treat them.

        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?

This argument can be dropped. It's really the same problem, and it's
only a minor point: a user can see "Set" or "Unchanged" (saved) for an
option at some point, and so perhaps feel reassured, and yet still
have the same problem when you restart Emacs.

You set an option in Customize, save it, then restart Emacs. Its value
in Customize is different from what you saved, because of an outside
change by a library. It makes no difference whether or not the value
you saved was first "Set". Set values and changed-outside values can
equally be overridden by subsequent outside changes. Just because you
set an option, so you don't see the "warning", is no guarantee that
the problem won't arise.
    
    	 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.

Yes, but those values don't differ in kind. The question is "_How_ can
a user set a value?" If a user uses a program to set a value,
intentionally, is it a user-set value or a program-set value?

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.

Is there is a good inside/outside boundary to choose? Which kinds of
changes should we allow inside the "Set" club?

Users will want to use commands that let them set user options, and
they will expect to see the resulting status in Customize as "Set".
Unless we can identify specific problems with specific levels
(1,2,3...), I'd say that _any_ change to a user option should be
allowed, because the important thing is the user's intention. Any
single cutoff level is a poor measure of intention.

But this is why I wanted a discussion. There may be good reasons,
unidentified so far, for using level 4 or 6 instead of 8 or 9. The
point is to recognize that it is, a priori, _good_ to open up
Customize to the rest of Emacs as much as possible - that is, up to a
level where we see problems with such openness.

IOW, a priori, any way to change a user option is a valid way for a
user to change an option. And all valid ways for a user to change an
option should be reflected in Customize as setting the option. That's
my argument.

The caveat here is that in order to open things up for users we also
need to close them down for Lisp code (and built-in C code -
e.g. `baud-rate') that is inappropriate. User options should not be
trounced indiscrimately by libraries - they are _user_ options. _If_
there is a real need for some library to change a user option (as
opposed to defining a standard value for the option), then maybe that
case should be dealt with specially, or maybe it signals a general
need to stop at level 6 (or whatever) - a fundamental problem.
    
        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.

I think we agree, IIUC. Users can use programs to set options. That
doesn't mean that any arbitrary program _should_ set user options. As
someone said earlier, the purpose of the library should explicitly
include and document setting an option.

I hope and expect, actually, that (beyond the bugs) few libraries will
ever need to change user options, at least not by simply being loaded.
Most will a) define standard values for options or b) provide commands
to set options or c) behave themselves properly by modifying only
non-user-option variables.

I should make a distinction here - there are libraries and libraries.
There are libraries that are intended for use by multiple users, and
there are libraries that are essentially custom files or personal
extensions thereof. Multi-user libraries are the ones that should not
step on user options. Personal libraries are made to set user options.

Some libraries (some of mine, for instance) start out life as a
personal library and end up being shared to some extent by others. In
some cases, user-option settings in a library shared this way are not
bothersome - if the person using the library has the same environment
and wants to do the same thing, for instance. This is essentially just
cutting and pasting code.

In general, however, a library destined for multiple users should not
contain user-option settings - that is bad form. I think it would be
good to mention this difference in library kind (purpose, really) in
the "good style" Elisp doc, along with a set of etiquette guidelines
(TBD) for real multi-user libraries.

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. See my separate "New tack" email for more on this
subject.

What about loading a personal library that sets user options _after_
startup? If I loan you such a file, and you want to try it but are not
sure that you want to add it as is to your startup file, you can load
it after startup and test drive it. If loading it sets user options
(e.g. setq), then those options should be marked "Set" in Customize.
You can then choose to add the library to your startup or perhaps
change a few settings and save some settings to your custom file.

Etiquette guidelines and setting a good example in the standard code
are the proper way to deal with the issue of libraries setting user
options. Although I expect that few multi-user libraries will really
need to set user options, especially during loading, I don't think a
rule (beyond etiquette) should be established against libraries
setting user options. That is, I vote for level #9 or #omega or
whatever: loading any library that changes user options "sets" those
options in Customize.

Unless we can identify problems with such an approach, of course.

Luc's investigations about hooks and other variable-length list
variables are right-on in this regard. That's the kind of thing to
examine: Just which kinds of program changes to user options are
appropriate? Can we find a cleaner way of dealing with hooks, which
leaves the "user" part of user hooks inviolate?

Trying to fix the pbs in the standard libraries will bring about a
better understanding and possibly new implementation techniques, which
can then be reflected in guidelines for developers of other libraries.
    
        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.

The price might depend on how it's done. You mentioned (albeit in
Customize only):

    treating a single list as if it were the combination of too list
    values, one to be edited through Custom and one to be updated by
    programs.

Or one to be defined/changed by users and one to be defined/changed by
Emacs internals.

If we want to do things to a hook by program, but we don't want to
consider the complete result to be the `standard' value for some
reason, and we also want to keep user stuff inviolable (no changes
behind the back), then one way or the other we will end up with two
parts of the same hook or two different hooks or two different ways to
access the hook or some other way to keep the two separate.

Some inappropriate user-option changes will, I expect, end up being
fixed by just using standard-value definitions instead - perhaps for
part of a hook, for instance.

        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.

100% agreement that we should consider them together. But we shouldn't
get them confused. It is not because there are bugs, which cause lots
of inappropriate "changed-outside" indications, that in a clean system
most outside changes would be inappropriate. Appropriate outside
changes should not be treated differently from inside changes - there
are many ways for a user to set a user option.

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

[Luc Teirlinck]

Drew Adams wrote:

   Do you mean that if all the bugs are fixed you will no longer prefer
   "outside" + "inside", that you will prefer just "changed" (set)?

I said that this would depend on the implementation details.

   If so, then there is no need (for you) for a user preference
   here. If not, then why would this be limited to 1-2 releases?

It _might_ be limited to two releases, depending on the implementation
details.  To me, that is sufficient reason not to implement an option
right now. 

   I meant arguments about the desirability in the UI of "outside" + "inside"
   vs just changed". I haven't seen those arguments.

>From my previous message:

   I believe that it is possible that we might still need "Set outside Custom"
   after fixing the hooks-listvars bugs.  If you have set an option in
   your .emacs ten years ago, you need some reminder that you actually
   set it in your .emacs, or you might have forgotten it.  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.

I believe that even after any reimplementation, a change made in
.emacs should definitely never be equated with something "Set for the
current session".  It is just as permanent as something set in the
custom-set-variables form.  If the "Set outside Custom" would be
replaced by something, it would be by a statement that the part
_controlled by Custom_ is at standard setting.  At least that would be
the case for hooks and similar list-vars.  For other options, we still
may need the "Set outside Custom", depending on what we do with them.

Sincerely,

Luc.

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

[Luc Teirlinck]

>From my previous message:

       If so, then there is no need (for you) for a user preference
       here. If not, then why would this be limited to 1-2 releases?

    It _might_ be limited to two releases,

I meant: _at most_ two releases.

Sincerely,

Luc.

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

[Luc Teirlinck]

Actually, I start thinking again that it _might_ be good to make _any_
option set in .emacs "untouchable" through Custom, even atoms and even
in as far as the current session is concerned.  That way we do not
need to make any distinction between hooks (and similar list-vars) and
other options, which probably will simplify implementation _a lot_,
things will look less inconsistent to the user _and_ it will avoid
problems if you later try to "Reset to Standard" (which would make no
sense).  If you customized in .emacs outside Custom, it is better to
be consistent and set it for the current session with set-variable.

If we do that, we probably will not need the "Set outside Custom" anymore.

At a given moment we will have to quit this discussion for now.  If we
think _too_ much about it now, we will have forgotten everything by
implementation time anyway.

Sincerely,

Luc.

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

[Luc Teirlinck]

>From my previous message:

    Actually, I start thinking again that it _might_ be good to make _any_
    option set in .emacs "untouchable" through Custom, even atoms and even
    in as far as the current session is concerned.

This was a misformulation.  I meant that the _part_ of the option
set through .emacs (the elements of the hook or listvar added in
.emacs) would be untouchable through Custom.  But, for an atom or
for hooks or list-vars _setq-ed_ in .emacs, that part is everything.

Sincerely,

Luc.

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

[Drew Adams]

    Actually, I start thinking again that it _might_ be good to make _any_
    option set in .emacs "untouchable" through Custom, even atoms and even
    in as far as the current session is concerned.  That way we do not
    need to make any distinction between hooks (and similar list-vars) and
    other options, which probably will simplify implementation _a lot_,
    things will look less inconsistent to the user _and_ it will avoid
    problems if you later try to "Reset to Standard" (which would make no
    sense).  If you customized in .emacs outside Custom, it is better to
    be consistent and set it for the current session with set-variable.

    This was a misformulation.  I meant that the _part_ of the option
    set through .emacs (the elements of the hook or listvar added in
    .emacs) would be untouchable through Custom.  But, for an atom or
    for hooks or list-vars _setq-ed_ in .emacs, that part is everything.

You mean that if I do (setq foo 50) in my .emacs I cannot then experiment
using Customize to change `foo' to 100 to see if I like that better? I can
save things from Customize to .emacs but I cannot change things in Customize
that have been set in .emacs?

I think such a design would be _very_ unfortunate.

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

[Drew Adams]

       I meant arguments about the desirability in the UI of
       "outside" + "inside" vs just changed". I haven't seen those
       arguments.

    From my previous message:

       I believe that it is possible that we might still need "Set
       outside Custom"
       after fixing the hooks-listvars bugs.  If you have set an option in
       your .emacs ten years ago, you need some reminder that you actually
       set it in your .emacs, or you might have forgotten it.  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.

    I believe that even after any reimplementation, a change made in
    .emacs should definitely never be equated with something "Set for the
    current session".  It is just as permanent as something set in the
    custom-set-variables form.  If the "Set outside Custom" would be
    replaced by something, it would be by a statement that the part
    _controlled by Custom_ is at standard setting.  At least that would be
    the case for hooks and similar list-vars.  For other options, we still
    may need the "Set outside Custom", depending on what we do with them.

Please see my message "New tack for Customize" (today). I think we agree now
about custom-file changes being reflected in Customize as neither "changed
outside" nor "set", but as "Custom File" (or another name with that
meaning). (This is not the same thing as `standard', BTW.)

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

[Luc Teirlinck]

Drew Adams wrote:

   You mean that if I do (setq foo 50) in my .emacs I cannot then experiment
   using Customize to change `foo' to 100 to see if I like that better?

You could experiment using `M-x set-variable', but really, I should not
have made _any_ further suggestions.  We should not decide on any
implementation details right now.  We will have forgotten them anyway
whenever, after the release, somebody finds the time to implement stuff.

Right now the important thing is to quit this discussion for now.

Sincerely,

Luc.

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

[Robert J. Chassell]

    I believe that even after any reimplementation, a change made in
    .emacs should definitely never be equated with something "Set for the
    current session".  It is just as permanent as something set in the
    custom-set-variables form. ...

Especially since custom-set-variables automatically writes into your
.emacs file.

Please, whenever you write about the custom-set-* applications, say

    automatically written into your .emacs file, rather than 
    written by you in your .emacs file

This way, it will never even occur to you that a change made in a
.emacs file might be "Set for the current session" only.

Thank you.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

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

[Richard Stallman]

    Of course, we have the similar problem that if we make an entry set
    with add-hook in .emacs untouchable, then the user can not undo it
    for the current session any more either, even though this is feasible
    and safe right now.

That is a good point.  It is harmless to change any value
just for the current session--the problems arise when you
try to save the change.

That creates a problem for solutions based on changing the way the
user edits the value.  However, they may not be insuperable.  One idea
is to offer the user a choice of two representations to edit: the
"safe" one that allows saving the result, and the "raw" one that
allows setting but not saving.

      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.

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

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

[Richard Stallman]

I 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 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.

The question you posed does not require an answer.

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?

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

[Luc Teirlinck]

Drew Adams wrote:

    Is there is a good inside/outside boundary to choose?

It is not entirely a matter of choice.  "inside Custom" and "outside
Custom" have _very_ precise meanings.  "inside" means that you are
in a situation where changing the value of the variable (permanently
or just for the current session) produces predictable results.
"outside" means that the code does not guarantee, or does not even
try, to produce predictable results.

A very basic assumption of the present Custom code is that _only_ the
user changes options defined with defcustom _and_ that either the user
_only_ changes them through Custom or _never_ changes them through
Custom.  The user can change some options inside Custom and some
outside, but not both for the _same option_.  Nothing in Custom's
current code even _tries_ to get "correct" results if this assumption
is false.  In that case, Custom just describes that state as "Set
outside Custom".  If you try to set or save it through Custom, the
resulting behavior is undefined.  If something strange happens as a
result, then Custom does not consider that a bug.  This does not mean
that setting or saving the option can not work correctly.  Maybe it
even works correctly most of the time.  _But_ if it works correctly,
it is by coincidence, not by design.

There are two things we can do.

The first one is eliminate the warning for individual options of which
we _know_ that the warning is bogus.  We are busy doing that and
trying to eliminate as much of those as we can _before_ the 22 release.

The second thing we could do is rewrite the Custom code so that it
produces predictable results in many frequent situations where it
currently does not.  This is _highly_ complex.  We definitely should
not even try to start doing _anything_ of this sort before 22 is out.
Depending on how shortly afterward 23 comes out, maybe not even before
23 is out.

Getting rid of the state would mean to come up with a design whereby
setting or saving _anything_ through Custom, _under any situation
whatsoever_ will _always_ work reliably.  I do not even believe that
this is theoretically, let alone practically, feasible.  What we can
try to do is make the state as infrequent as possible.  One could, of
course, rename the state to something like "Not controlled by Custom".

Sincerely,

Luc.

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

[Richard Stallman]

    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

Why do we need to discuss this question?  I thougth we were talking
about a question of advice to programmers.  Advice to programmers does
not need to be based on a mechanical distinction.

    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?

That seems to be pretty close to a restatement of what I said.
Whether it is exactly equivalent, I am not sure.

I am overloaded today and your message is too long for me to read.
Sorry, I don't have much time available for this now.