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: custom-declare-variable Date: Tue, 5 Jul 2005 20:34:12 -0500 (CDT) Message-ID: <200507060134.j661YCO21585@raven.dms.auburn.edu> References: <200507042320.j64NKNe15629@raven.dms.auburn.edu> <200507042337.j64Nbel15654@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1120614136 9560 80.91.229.2 (6 Jul 2005 01:42:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2005 01:42:16 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 03:42:07 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DpyvK-0004gd-DM for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2005 03:42:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dpywc-0001b1-73 for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2005 21:43:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DpytC-0007Lw-Rz for emacs-devel@gnu.org; Tue, 05 Jul 2005 21:39:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DpytA-0007Kn-Ti for emacs-devel@gnu.org; Tue, 05 Jul 2005 21:39:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dpyt9-0007J9-9t for emacs-devel@gnu.org; Tue, 05 Jul 2005 21:39:47 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dpyw1-0000Kv-Uk for emacs-devel@gnu.org; Tue, 05 Jul 2005 21:42:46 -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 j661aGCK004212; Tue, 5 Jul 2005 20:36:16 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j661YCO21585; Tue, 5 Jul 2005 20:34:12 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: storm@cua.dk In-reply-to: (storm@cua.dk) 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:40484 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40484 Kim Storm wrote: I've seen little evidence that anybody is actually using custom themes in its current form, so it can hardly be an "important feature" that should uphold the release. Maybe it might be good to give an overview of the presently available alternatives to Custom Themes and what their advantages and disadvantages are compared to Custom themes. From this comparison, it would appear that Custom Themes fill a need and are worth implementing, but it also makes it is obvious that there is no sense in rushing them hastily into Emacs 22. There is the reportedly widely used and popular color-theme.el. I believe that color-themes can not be disabled. They use setq and setq does not work well with Custom. Global minor modes can be used as themes. They have the big advantage of being _total_ customization themes, working for keybindings and other stuff, as well as for user options. They can be disabled. To properly disable the mode, the mode has to store the current value of an option when it changes it, to restore it when the mode is disabled. That works OK, because the option's value is usually essential to the proper functioning of the minor mode, so the user should not change it while the minor mode is enabled. Minor modes use setq, but in this case, this is probably ideal, because Custom will and _should_ tell the user that customizing the option may not work as expected. This seems to be the case with cua-mode, for instance, which sets transient-mark-mode to t and which, if I understand correctly, makes not much sense without that. So what would be the advantages of (properly implemented) Custom themes? In as far as I see it, there is are only two (closely related) advantages. Firstly, unlike color-themes, Custom Themes work well with Custom. Secondly, they can not only be disabled (minor modes can too), but, unlike with global minor modes, the user can safely override the values they set with other themes or through Custom (but not using setq). Themes and Custom store information allowing for proper conflict resolution (setq does not). (These advantages apply to _properly implemented_ Custom Themes, not to whatever the current code is trying to implement.) The advantage only exists if conflict resolution is implemented in a 100% accurate and intuitive fashion. There is no sense in Custom Themes that more or less work. People will not use them if they do not work 100%. They will use color-theme.el or global minor modes. Sincerely, Luc.