emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changed outside --> set, in Customize UI


From: Luc Teirlinck
Subject: Re: Changed outside --> set, in Customize UI
Date: Fri, 11 Feb 2005 17:05:54 -0600 (CST)

Drew Adams wrote:

    Is there is a good inside/outside boundary to choose?

It is not entirely a matter of choice.  "inside Custom" and "outside
Custom" have _very_ precise meanings.  "inside" means that you are
in a situation where changing the value of the variable (permanently
or just for the current session) produces predictable results.
"outside" means that the code does not guarantee, or does not even
try, to produce predictable results.

A very basic assumption of the present Custom code is that _only_ the
user changes options defined with defcustom _and_ that either the user
_only_ changes them through Custom or _never_ changes them through
Custom.  The user can change some options inside Custom and some
outside, but not both for the _same option_.  Nothing in Custom's
current code even _tries_ to get "correct" results if this assumption
is false.  In that case, Custom just describes that state as "Set
outside Custom".  If you try to set or save it through Custom, the
resulting behavior is undefined.  If something strange happens as a
result, then Custom does not consider that a bug.  This does not mean
that setting or saving the option can not work correctly.  Maybe it
even works correctly most of the time.  _But_ if it works correctly,
it is by coincidence, not by design.

There are two things we can do.

The first one is eliminate the warning for individual options of which
we _know_ that the warning is bogus.  We are busy doing that and
trying to eliminate as much of those as we can _before_ the 22 release.

The second thing we could do is rewrite the Custom code so that it
produces predictable results in many frequent situations where it
currently does not.  This is _highly_ complex.  We definitely should
not even try to start doing _anything_ of this sort before 22 is out.
Depending on how shortly afterward 23 comes out, maybe not even before
23 is out.

Getting rid of the state would mean to come up with a design whereby
setting or saving _anything_ through Custom, _under any situation
whatsoever_ will _always_ work reliably.  I do not even believe that
this is theoretically, let alone practically, feasible.  What we can
try to do is make the state as infrequent as possible.  One could, of
course, rename the state to something like "Not controlled by Custom".

Sincerely,

Luc.






reply via email to

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