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: More bugs in Custom themes Date: Tue, 5 Jul 2005 21:39:12 -0500 (CDT) Message-ID: <200507060239.j662dCR21612@raven.dms.auburn.edu> References: <200506300152.j5U1qBo01566@raven.dms.auburn.edu> <200507010104.j6114rD07388@raven.dms.auburn.edu> <200507030215.j632FHG09392@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1120618752 18120 80.91.229.2 (6 Jul 2005 02:59:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2005 02:59:12 +0000 (UTC) Cc: Per Abrahamsen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 04:59:11 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dq07e-00040x-J9 for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2005 04:58:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dq08w-0002ZG-8U for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2005 23:00:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dq08M-0002Xr-A8 for emacs-devel@gnu.org; Tue, 05 Jul 2005 22:59:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dq071-0002EP-2k for emacs-devel@gnu.org; Tue, 05 Jul 2005 22:58:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dq06y-00028N-Ed for emacs-devel@gnu.org; Tue, 05 Jul 2005 22:58:08 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dpzwp-0003z1-5X; Tue, 05 Jul 2005 22:47:39 -0400 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 j662fGCK004371; Tue, 5 Jul 2005 21:41:16 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j662dCR21612; Tue, 5 Jul 2005 21:39:12 -0500 (CDT) 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-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:40487 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40487 Richard Stallman wrote: "A proper design" doesn't identify a specific problem I could address, The very first design decision to be made is: what do we want Custom Themes to be and how do we want them to be used. I do not even know what _kind_ of Custom Themes the current code is trying to implement or how it wants them to be used. There are no interactive declarations in the code, so _maybe_ they are only meant for use in initialization files, to be executed _before_ any custom-set-{variables,faces} forms. (_Both_ enabling and unsetting of themes seems to have to occur before these forms. No enabling or unsetting after them, in particular, no _interactive_ enabling or unsetting.) The code _seems_ to assume that no two themes (including the `user' theme, but, of course, excluding the standard theme) contain customizations for the same variable. If all these assumptions are strictly adhered to, many of the worst bugs no longer occur. There would still be bugs left, but they might be fixable. But I seem to have understood that we want something more powerful. Then I believe that we need a complete rewrite of the current code, essentially starting from scratch. I believe I understood that we want to allow multiple Custom Themes, possibly setting conflicting values for the same option, that can be _interactively_ (as well as in init files) enabled or disabled in any order, interspersed with arbitrary saving, setting, and resetting to standard value, and that we even want to handle interspersed setq's in a reasonable way. I seem to have understood that this is what users want. I believe that it is possible (but _not_ trivial) to implement all of that in a clean and intuitive way. I believe that it has to be done very carefully. The current code uses `requiring' to enable Themes. Re-enabling a Theme has no effect if it has ever been loaded previously, so it does not reinstate "clobbered" values. I believe we agreed that this was a problem and that user convenience dictates replacing requiring with unconditional loading as the fundamental Theme enabling mechanism. This is a second fundamental design departure from the present code. Then comes the conflict resolution algorithm (I will address that in a second message). Sincerely, Luc.