From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: color-theme.el Date: Sat, 31 Aug 2002 12:58:11 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020824043224.GC20524@reactor-core.org> <87r8goqjzt.fsf@emacswiki.org> <87vg5vlwlr.fsf@emacswiki.org> <87ofbmomnm.fsf@emacswiki.org> Reply-To: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1030813228 29054 127.0.0.1 (31 Aug 2002 17:00:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 31 Aug 2002 17:00:28 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17lBbn-0007YV-00 for ; Sat, 31 Aug 2002 19:00:27 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17lC98-0001n7-00 for ; Sat, 31 Aug 2002 19:34:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17lBdD-0007LX-00; Sat, 31 Aug 2002 13:01:55 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17lBZe-0007Cz-00 for emacs-devel@gnu.org; Sat, 31 Aug 2002 12:58:14 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17lBZc-0007Ch-00 for emacs-devel@gnu.org; Sat, 31 Aug 2002 12:58:13 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17lBZb-0007Cb-00 for emacs-devel@gnu.org; Sat, 31 Aug 2002 12:58:11 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 17lBZb-0007Mw-00; Sat, 31 Aug 2002 12:58:11 -0400 Original-To: alex@emacswiki.org In-Reply-To: <87ofbmomnm.fsf@emacswiki.org> (message from Alex Schroeder on Wed, 28 Aug 2002 20:37:01 +0200) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7210 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7210 I think we could write something like that without the need for cus-theme.el. A wizard using widget.el that lets you specify the variables that are part of the theme, the name of theme, and a file name. It would then save the appropriate lisp code -- a bunch of setq statements (in a defun, with appropriate call to `provide'). We would then modify the `startup-functions' idea I presented in an earlier mail: Let it be called `startup-requires'. Users could then save the file with the generated setq statements in their load-path, and customize `startup-requires' such that the appropriate theme is loaded, and the variables are set, at startup time. This would provide the user experience you describe, with very little work required. This may not be a very large job, but the first part is not trivial--do you want to do it? As for the feature of using multiple themes, of being able to add and remove themes from the list and have the right thing happen, I think I see an easy way to add that. We just have to make sure that each theme function saves the old values of the variables that it sets, so that it can "turn itself off" later on. Then, when the user edits the list of currently enabled themes, here's what you do. You turn off all the themes in the list, in reverse order. You change the list. Then you turn on the themes that are now in the list. > The problem is that any individual option set by "setq" from a funtion > in such a list will overwrite the users individual customization of > that item. With Jans themes it is the other way around, the explicit > individual settings will overwrite the the settings. If we want that, let the customization of `startup-requires' be the first thing acted upon when doing customization. That would work at startup. To make it work right for editing the list later would take a little more. These theme functions could carefully avoid setting variables that are marked as customized. This probably means that instead of using setq directly, they should use a macro `theme-setq' to set each variable. The macro would take care of recording the old value, not setting variables that are customized, etc. Would this give equivalent benefits to cus-theme.el? Your scheme won't integrate cleanly with customize (the option will be marked "rogue", i.e. "option is changed outside customize"), which is my major emotional problem with it. Would it be difficult to create a new status value, "set by a theme"? theme-setq could mark the variable with this status. Meanwhile, would anyone be willing to step forward to integrate cus-theme.el into Emacs?