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 22:32:47 -0500 (CDT) Message-ID: <200507060332.j663WlA21625@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 1120622405 24248 80.91.229.2 (6 Jul 2005 04:00:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2005 04:00:05 +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 06:00:03 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dq14e-0000Up-Rn for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2005 05:59:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dq15w-00019g-MN for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2005 00:01:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dq0zl-0007QN-I2 for emacs-devel@gnu.org; Tue, 05 Jul 2005 23:54:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dq0zW-0007Ki-LC for emacs-devel@gnu.org; Tue, 05 Jul 2005 23:54:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dq0zW-0007E4-IT for emacs-devel@gnu.org; Tue, 05 Jul 2005 23:54:30 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dq0mj-0006es-8o; Tue, 05 Jul 2005 23:41:17 -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 j663YrCK004584; Tue, 5 Jul 2005 22:34:53 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j663WlA21625; Tue, 5 Jul 2005 22:32:47 -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:40491 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40491 but I think we already discussed the proper conflict resolution method. What I suggested was that the themes are listed in an order, and later themes override earlier themes. It is a little bit more complex than that. The user can enable or disable themes, save options through Custom, set them through Custom, reset them to standard through Custom and change them using setq. In each possible situation, you need to decide how to determine the actual value, saved-value, theme-value (or theme-face), backup-value and customized-value. Maybe the answers are obvious in each case, but each combination of cases has to be thought about. I believe that mainly the actual value (the case we have been worrying about) is not completely trivial. However, I also have my doubts about the way the current code handles `saved-value'. Related to the latter problem is yet another design decision to be made. When the option has been set by a theme, the current code says that it has been "Saved and set". I believe that this is unhelpful and confusing and that it should say instead that it has been set by a theme, preferably saying which theme. This probably requires handling saved-value differently. Disabling any of the themes works by getting rid of all of them, then reloading the ones that remain enabled. To me, that seems to be a contorted way to do it. Also, do not forget that when the user asks to disable a theme, the value you want to restore will sometimes be a setq-ed value, thus not associated with any theme, and that you also have to make sure that your method gets all stored info right, not just the actual value. You've already got the function which turns them all off. You mean `custom-do-theme-reset'? That is the very last function I would want to use, rely on or emulate if I were you. It indeed turns them _all_ off, but then _pretends_ that it only turned one off by just removing one from theme-value (or theme-face). Looks like a badly messed up function to me, but since I have no idea what that code is trying to _accomplish_ (although I know perfectly what it _does_), I may be wrong. If you think it would be hard to write this, could you tell me which functions deal with this part of things? Then I will try. `custom-do-theme-reset' I am afraid. Again, I would not take a lot of my inspiration from that one if I were you. I believe that a function to properly disable a theme has to be written from scratch. But you will probably have to rewrite plenty of other stuff before you can begin to rewrite that one. Of course, the function to enable themes will also have to be rewritten to use unconditional loading instead of requiring, but that is probably easier. It is actually my impression that most of the code needs to be rewritten. Maybe some stuff can be recycled in one form or another into the new design. Sincerely, Luc.