From: "Drew Adams" <drew.adams@oracle.com>
Cc: Emacs-Devel <emacs-devel@gnu.org>
Subject: RE: Changed outside --> set, in Customize UI
Date: Mon, 7 Feb 2005 10:04:04 -0800 [thread overview]
Message-ID: <MEEKKIABFKKDFJMPIOEBMEFPCJAA.drew.adams@oracle.com> (raw)
In-Reply-To: <874qgoo4j7.fsf-monnier+emacs@gnu.org>
> 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?
next prev parent reply other threads:[~2005-02-07 18:04 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 [this message]
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
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=MEEKKIABFKKDFJMPIOEBMEFPCJAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
--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.