[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changed outside --> set, in Customize UI
From: |
Richard Stallman |
Subject: |
Re: Changed outside --> set, in Customize UI |
Date: |
Mon, 07 Feb 2005 15:51:44 -0500 |
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, (continued)
- RE: Changed outside --> set, in Customize UI, Drew Adams, 2005/02/08
- Re: Changed outside --> set, in Customize UI, Luc Teirlinck, 2005/02/08
- Re: Changed outside --> set, in Customize UI, Luc Teirlinck, 2005/02/08
- RE: Changed outside --> set, in Customize UI, Drew Adams, 2005/02/08
- Re: Changed outside --> set, in Customize UI, Robert J. Chassell, 2005/02/09
- Re: Changed outside --> set, in Customize UI, Luc Teirlinck, 2005/02/08
- RE: Changed outside --> set, in Customize UI, Drew Adams, 2005/02/08
- Re: Changed outside --> set, in Customize UI, Luc Teirlinck, 2005/02/08
- Re: Changed outside --> set, in Customize UI, Luc Teirlinck, 2005/02/08
Re: Changed outside --> set, in Customize UI, Lennart Borgman, 2005/02/07
Re: Changed outside --> set, in Customize UI,
Richard Stallman <=
- RE: Changed outside --> set, in Customize UI, Drew Adams, 2005/02/08
- Re: Changed outside --> set, in Customize UI, Richard Stallman, 2005/02/10
- RE: Changed outside --> set, in Customize UI, Drew Adams, 2005/02/11
- Re: Changed outside --> set, in Customize UI, Luc Teirlinck, 2005/02/11
- Re: Changed outside --> set, in Customize UI, Richard Stallman, 2005/02/12