[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Eliminating "changed in Emacs outside of Customize"
From: |
Drew Adams |
Subject: |
RE: Eliminating "changed in Emacs outside of Customize" |
Date: |
Tue, 1 Feb 2005 12:38:11 -0800 |
> Was this unclear:
> If you .emacs, or some third party code you
> activate from ".emacs", contains "(setq foo 42)" and
you change and
> save "foo" from customize, you changes to the variable through
> customize will be overwritten next time you start Emacs.
It's crystal clear to me, but let me try to rephrase it, to see
if it helps other people:
- Let's imagine user Helen has had a (setq-default
fill-column 42) in her
.emacs (or maybe it's in some package that she doesn't
even remember
she's loading from a .emacs).
- Now let's imagine that Helen notices that her fill-column
is too small
and she wants to set it to something else, like 70.
- She does M-x customize-variable RET fill-column RET, then
changes the
value, then saves.
- When she restarts, fill-column is 42 again.
- Since she's not arrogant, she figures she must have made a
mistake so
she goes through the customize-variable thingy again.
- When she restarts, fill-column is still stuck at 42.
- Then comes M-x report-emacs-bug.
Of course the above problem will only happen if the (setq-default
fill-column 42) happens to be executed after Helen's
custom-set-variables
(e.g. in a mode-hook or in one of the many poorly written major
modes that
happily mess up global variables).
Right. I believe that's exactly the behavior I described, as well.
What is not at all clear (to me) is what this has to do with the supposed
need to distinguish, for the user, a value that is changed using a customize
buffer from a value that is changed otherwise. The original question was
that: "What would be wrong with treating, in the Customize UI, outside
changes the same as inside changes?"
IOW, nothing in the above description (Stefan's or Per's) makes any mention
of replacing "changed outside" by "set" in the Customize UI. The above
description holds perfectly in today's vanilla Emacs, does it not?
If so, are we in fact getting such bug reports from Helen? If so, then maybe
something could be done to make the behavior clearer to her.
Beyond that, what does this have to do with the question: "What would be
wrong with treating outside changes the same as inside changes - in the
Customize UI?"
- Drew
- Re: Eliminating "changed in Emacs outside of Customize", (continued)
- RE: Eliminating "changed in Emacs outside of Customize", Drew Adams, 2005/02/03
- Re: Eliminating "changed in Emacs outside of Customize", Lennart Borgman, 2005/02/01
- Re: Eliminating "changed in Emacs outside of Customize", Luc Teirlinck, 2005/02/01
- RE: Eliminating "changed in Emacs outside of Customize", Drew Adams, 2005/02/01
- Re: Eliminating "changed in Emacs outside of Customize", Luc Teirlinck, 2005/02/01
- Re: Eliminating "changed in Emacs outside of Customize", Luc Teirlinck, 2005/02/01
- Re: Eliminating "changed in Emacs outside of Customize", Richard Stallman, 2005/02/03
- RE: Eliminating "changed in Emacs outside of Customize", Drew Adams, 2005/02/01
- RE: Eliminating "changed in Emacs outside of Customize",
Drew Adams <=
- Re: Eliminating "changed in Emacs outside of Customize", Lennart Borgman, 2005/02/01
- Re: Eliminating "changed in Emacs outside of Customize", Richard Stallman, 2005/02/03
- Re: Eliminating "changed in Emacs outside of Customize", Per Abrahamsen, 2005/02/02
- RE: Eliminating "changed in Emacs outside of Customize", Drew Adams, 2005/02/02
- Re: Eliminating "changed in Emacs outside of Customize", Lennart Borgman, 2005/02/02
- RE: Eliminating "changed in Emacs outside of Customize", Drew Adams, 2005/02/02
- Re: Eliminating "changed in Emacs outside of Customize", Stefan Monnier, 2005/02/02
- Re: Eliminating "changed in Emacs outside of Customize", Luc Teirlinck, 2005/02/02
- Re: Eliminating "changed in Emacs outside of Customize", Lennart Borgman, 2005/02/03
- Re: Eliminating "changed in Emacs outside of Customize", Lennart Borgman, 2005/02/03