[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: Wed, 2 Feb 2005 14:11:22 -0800

    > I still have the specific question of _what the problem is_ with the
    > scenario that you and Stefan (and I) described: a setq (in .emacs or a
    > library) executed after custom-set-variables. Yes, a setq changes the
    > current value so that it is no longer the `saved-value' - but so what?

    The novice user changes a value in customize, saves and
    restarts Emacs. Then
    he find that the value is still the same. His conclusion is
    that there is
    something wrong with Emacs. He does not dare to use it any more.

Yes (here we go 'round again) - that is exactly the behavior that we have
_today_, in spite of our blessed distinction between "changed outside
customize" and "set within customize".

What is the specific problem that Per and Stefan think would result from
treating "changed outside" as "set"?  IOW, what does this "pb" have to do
with a proposal to subsume "changed outside" under "set"?

We were told that this pb would result in users making bug reports _if_ we
treated "changed outside" as "set", but there has been no explanation of the
connection between this pb and that proposed enhancement.

The pb as described exists today, yet we don't seem swamped with such bug
reports. And even if we were, that pb has nothing to do with the question at
hand - at least nothing that has been pointed out yet.

So, I don't get it - what's the real pb here in connection with "changed
outside" vs "set"?

    >     The original question was that: "What would be wrong
    >     with treating, in the Customize UI, outside changes the same as
    >     inside changes?"

    I think the distinction is good.

Why? Will someone please tell me _why_ it is good? That was the original
question. To which question we got the scenario we're all familiar with by
now. But I don't see how that scenario shows why this distinction is good.
The "pb" pointed to by that scenario is independent of whether we keep this
distinction or get rid of it (for the UI).

Or, if it is not independent, please show the connection.

    It was however very confusing the first
    time I saw it. When I now see the distinction between user
    variables (should
    only be changed by the user) and others it is much more clear.
    Should not
    this distinction should be pointed out very clearly in Info under Easy

Which distinction? The distinction between "changed outside" and "set" for
user options or the distinction between user variables and non-user
variables? Why bring up the latter in the context of this discussion?

 - Drew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]