From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Bug, probably related to Custom Themes. Date: Thu, 22 Dec 2005 22:04:25 -0600 (CST) Message-ID: <200512230404.jBN44PW18269@raven.dms.auburn.edu> References: <200512210254.jBL2sj814876@raven.dms.auburn.edu> <87mziuqp2x.fsf@stupidchicken.com> <200512211840.jBLIefx25655@raven.dms.auburn.edu> <87vexiw3w4.fsf@stupidchicken.com> <200512212258.jBLMwt329838@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1135310821 16461 80.91.229.2 (23 Dec 2005 04:07:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Dec 2005 04:07:01 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 23 05:06:59 2005 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EpeCh-0003Tm-9p for ged-emacs-devel@m.gmane.org; Fri, 23 Dec 2005 05:06:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpeDi-00068i-Pv for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2005 23:07:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EpeDQ-00068U-Px for emacs-devel@gnu.org; Thu, 22 Dec 2005 23:07:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EpeDQ-00068I-9R for emacs-devel@gnu.org; Thu, 22 Dec 2005 23:07:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpeDQ-00068F-5F for emacs-devel@gnu.org; Thu, 22 Dec 2005 23:07:36 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EpeCd-0007U3-Os; Thu, 22 Dec 2005 23:06:47 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id jBN46Nsx009236; Thu, 22 Dec 2005 22:06:24 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id jBN44PW18269; Thu, 22 Dec 2005 22:04:25 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (rms@gnu.org) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Thu, 22 Dec 2005 22:06:24 -0600 (CST) 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 Xref: news.gmane.org gmane.emacs.devel:48236 Archived-At: Loading a theme means installing a new set of defaults. "Erase Customization" should restore the theme value. If the user wants the no-themes default, he should set and save bar in a Custom buffer to the no-themes default, thereby making the no-theme default the user theme value which explicitly overrides any theme, present or future. That is the only way one can be consistent. I agree. In what way does the current behavior differ from that? After some checking, things are really bad. The behavior is that with _and_ without my patch, "Erase Customization" resets to the no-theme default _for the current session_. Hence my patch does not completely fix the bug. I suggest that, until a real fix would be installed (which will take time), we install my patch anyway, because it will at least prevent CVS user's .emacs from getting messed up (_even_ if they use no themes). My patch will be part of any real fix anyway, it just is not the complete fix. For people who do not use themes, it _is_ a complete fix. The "Themes" code is completely and hopelessly messed up. It needs to be rewritten from scratch. Themes should change the standard-value property, not the saved-value one, since they change the default values. There should be no user "theme", but there probably should be a standard theme. The "Themes" code should not try to rewrite cus-edit. If `load-theme' and `disable-theme' correctly update the standard-value, there is no need for Custom to know anything about themes. Except for one thing: there needs to be a "theme" custom state, just to tell the user in a Custom buffer that the value was set by a theme (other than the standard theme). `load-theme' and 'disable-theme' should keep track of that, Custom should not have to worry about it. If the user uses no themes, the "Themes" code should not be loaded at all. This way, you do not need to understand the Themes code to understand the Custom code (which hence gets more transparent) and bugs in the Themes code can never mess up all of Custom. The Themes code itself would be a lot simpler than the contorted current mess, which nobody is able to understand and which does not work. For Themes to be able to handle hooks and list-vars in any satisfactory way, the bugs in Custom concerning hooks and list-vars would need to be fixed. I believe that trying to fix the current Themes code is hopeless. It _needs_ to be rewritten from scratch. Either we should delay introduction of Themes until Emacs 23 (this is what I personally recommend), or we should completely rewrite it (and probably fix the hook bugs in Custom too) before the release. If we want to do the latter, we are talking about at the very least six months before a pretest could start, probably more than a year. Sincerely, Luc.