From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Changed outside --> set, in Customize UI Date: Fri, 11 Feb 2005 17:05:54 -0600 (CST) Message-ID: <200502112305.j1BN5sI16636@raven.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1108163306 7698 80.91.229.2 (11 Feb 2005 23:08:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Feb 2005 23:08:26 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 12 00:08:25 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CzjtX-0000dq-IE for ged-emacs-devel@m.gmane.org; Sat, 12 Feb 2005 00:08:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Czk8Y-0004ty-Se for ged-emacs-devel@m.gmane.org; Fri, 11 Feb 2005 18:23:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Czk74-0004Wv-8h for emacs-devel@gnu.org; Fri, 11 Feb 2005 18:22:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Czk6s-0004Qm-7F for emacs-devel@gnu.org; Fri, 11 Feb 2005 18:22:06 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Czk6r-0004Og-CU for emacs-devel@gnu.org; Fri, 11 Feb 2005 18:22:01 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Czjsr-0007N2-59; Fri, 11 Feb 2005 18:07:33 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j1BN7W9N017669; Fri, 11 Feb 2005 17:07:32 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j1BN5sI16636; Fri, 11 Feb 2005 17:05:54 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: drew.adams@oracle.com In-reply-to: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33272 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33272 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.