From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Changed outside --> set, in Customize UI
Date: Mon, 07 Feb 2005 15:51:44 -0500 [thread overview]
Message-ID: <E1CyFrE-0006kK-Rb@fencepost.gnu.org> (raw)
In-Reply-To: <MEEKKIABFKKDFJMPIOEBIEFOCJAA.drew.adams@oracle.com>
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.
next prev parent reply other threads:[~2005-02-07 20:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-07 7:35 Changed outside --> set, in Customize UI Drew Adams
2005-02-07 14:01 ` Stefan Monnier
2005-02-07 18:04 ` Drew Adams
2005-02-07 18:51 ` Stefan Monnier
2005-02-08 20:37 ` Drew Adams
2005-02-08 3:15 ` Luc Teirlinck
2005-02-08 4:00 ` Luc Teirlinck
2005-02-08 11:55 ` Luc Teirlinck
2005-02-10 6:02 ` Richard Stallman
2005-02-08 20:37 ` Drew Adams
2005-02-09 1:38 ` Luc Teirlinck
2005-02-09 2:27 ` Drew Adams
2005-02-09 13:29 ` Robert J. Chassell
2005-02-09 1:44 ` Luc Teirlinck
2005-02-09 2:07 ` Luc Teirlinck
2005-02-09 2:27 ` Drew Adams
2005-02-09 2:45 ` Luc Teirlinck
2005-02-09 2:15 ` Luc Teirlinck
2005-02-07 16:14 ` Lennart Borgman
2005-02-07 20:51 ` Richard Stallman [this message]
2005-02-08 20:38 ` Drew Adams
2005-02-10 6:02 ` Richard Stallman
2005-02-11 21:15 ` Drew Adams
2005-02-11 23:05 ` Luc Teirlinck
2005-02-12 19:17 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1CyFrE-0006kK-Rb@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.