From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Per Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: color-theme.el Date: Wed, 28 Aug 2002 16:37:16 +0200 Organization: The Church of Emacs Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020824043224.GC20524@reactor-core.org> <87r8goqjzt.fsf@emacswiki.org> <87vg5vlwlr.fsf@emacswiki.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1030545504 25072 127.0.0.1 (28 Aug 2002 14:38:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 28 Aug 2002 14:38:24 +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 17k3xW-0006Vs-00 for ; Wed, 28 Aug 2002 16:38:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17k4TM-00068k-00 for ; Wed, 28 Aug 2002 17:11:08 +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 17k3yt-000822-00; Wed, 28 Aug 2002 10:39:39 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17k3wj-0007vJ-00 for emacs-devel@gnu.org; Wed, 28 Aug 2002 10:37:25 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17k3wg-0007v7-00 for emacs-devel@gnu.org; Wed, 28 Aug 2002 10:37:24 -0400 Original-Received: from sheridan.dina.kvl.dk ([130.225.40.227]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17k3wg-0007v3-00 for emacs-devel@gnu.org; Wed, 28 Aug 2002 10:37:22 -0400 Original-Received: from zuse.dina.kvl.dk (zuse.dina.kvl.dk [130.225.40.245]) by sheridan.dina.kvl.dk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA16499; Wed, 28 Aug 2002 16:37:21 +0200 Original-Received: (from abraham@localhost) by zuse.dina.kvl.dk (8.9.3+Sun/8.9.3) id QAA14995; Wed, 28 Aug 2002 16:37:16 +0200 (MEST) X-Authentication-Warning: zuse.dina.kvl.dk: abraham set sender to abraham@dina.kvl.dk using -f Original-To: Alex Schroeder X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ In-Reply-To: <87vg5vlwlr.fsf@emacswiki.org> (Alex Schroeder's message of "Wed, 28 Aug 2002 01:18:08 +0200") Original-Lines: 58 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.1 (sparc-sun-solaris2.8) 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:7057 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7057 Alex Schroeder writes: > Per Abrahamsen writes: > > First, let us look at the kind of effort involved in using > cus-theme.el. To create a theme involves about as much work as > writing a setq statement for all the variables, and giving this > collection of settings a name. So for an author, there is no benefit > compared to writing a defun. The defun has a name and can set tons of > variables. The benefit for users is that undoing the theme is > straightforward. Jan Vroonhofs code is only the first (Lisp) step, the second step would be to add theme commands to the customize UI, like "add setting to theme", and "save theme". This would allow users with no knowledge of Lisp to create and share customizations, and, in my opinion, give them a first taste of the free software culture of sharing. They already do this, but they share entire "customize-set-variables" sections, which we know doesn't work well. > If this is the only benefit, It isn't. Large packages like Gnus can offer "build-in" themes for e.g. slow and fast connections, and fancy and boring display (which in Gnus involves much more than just faces). Emacs itself could come with some themes, such as an "Emacs 20" theme for people who dislike the UI changes in Emacs 21. > however, then perhaps we are better off with another solution > altogether: Let us create a new list of functions to call at > startup. Let us call it `startup-functions'. Let us make this > customizable. Now site authors can install a suitable default, and > users can still customize it to their liking. The customizations > will be saved to their .emacs file. Problem solved! And the > solution was easy to understand. 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. This benefit come both from package themes, other users themes, and site themes. They could all be done with functions and setq, but Jans themes makes it possible to prioritize them when they conflict, and overwrite individual options. > "As far as I am concerned, these last years have shown that there is > just no need for that." I don't think you can scale the experience gained from the existence of an unbundled package, to themes being integrated in Emacs. Hopefully, the later will mean many more themes will be available, with increasing need for conflict resolution and overwriting individual choises.