From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alex Schroeder Newsgroups: gmane.emacs.devel Subject: Re: color-theme.el Date: Wed, 28 Aug 2002 01:18:08 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <87vg5vlwlr.fsf@emacswiki.org> References: <20020824043224.GC20524@reactor-core.org> <87r8goqjzt.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 1030490222 31258 127.0.0.1 (27 Aug 2002 23:17:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2002 23:17:02 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17jpZz-000881-00 for ; Wed, 28 Aug 2002 01:16:59 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17jq5V-0001FP-00 for ; Wed, 28 Aug 2002 01:49:33 +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 17jpbI-0006zB-00; Tue, 27 Aug 2002 19:18:20 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jpZg-0006yF-00 for emacs-devel@gnu.org; Tue, 27 Aug 2002 19:16:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jpZd-0006xq-00 for emacs-devel@gnu.org; Tue, 27 Aug 2002 19:16:39 -0400 Original-Received: from relay02.cablecom.net ([62.2.33.102]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jpZd-0006xm-00 for emacs-devel@gnu.org; Tue, 27 Aug 2002 19:16:37 -0400 Original-Received: from smtp.swissonline.ch (mail-4.swissonline.ch [62.2.32.85]) by relay02.cablecom.net (8.12.5/8.12.5/SOL/AWF/MXRELAY/20020820) with ESMTP id g7RNGZWs045878 for ; Wed, 28 Aug 2002 01:16:35 +0200 (CEST) (envelope-from alex@emacswiki.org) Original-Received: from confusibombus (dclient217-162-239-43.hispeed.ch [217.162.239.43]) by smtp.swissonline.ch (8.11.6/8.11.6/SMTPSOL/AWF/2002040101) with ESMTP id g7RNGYH28970 for ; Wed, 28 Aug 2002 01:16:34 +0200 (MEST) Original-Received: from alex by confusibombus with local (Exim 3.35 #1 (Debian)) id 17jpb6-0000G0-00 for ; Wed, 28 Aug 2002 01:18:08 +0200 Original-To: emacs-devel@gnu.org X-Face: ^BC$`[IcggstLPyen&dqF+b2'zyK#r.mU*'Nms}@&4zw%SJ#5!/7SMVjBS7'lb;QK)|IPU5U'o1'522W4TyzB3Ab*IBo^iw]l4|kUbdZuUDO6=Um-.4IzhNiV'B"@K#jy_(wW|Zbk[34flKY^|PrQ?$u2\fKg^]AY>wOX#H32i In-Reply-To: (Per Abrahamsen's message of "Mon, 26 Aug 2002 14:45:40 +0200") Original-Lines: 85 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2.90 (i686-pc-linux-gnu) 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:7002 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7002 Per Abrahamsen writes: > I think there is plenty of need, but nobody both able and willing to > do the work. I tried to re-sync custom with the XEmacs version a > couple of years ago (which would have got us themes), and quickly > burned out. Since RMS is interested, let me explain my position. I worked on porting the XEmacs code by Jan Vroonhof to Emacs, so I know something about the code. (I actually met him in person in Zuerich before doing it!) I think the code is complex. I really tried to make it happen. I even proposed a solution to make alists customizable. This was one of the open problems. And yet, I am convinced that we do not need this complexity. We should not bother. Why? 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. Now, let us look at the scenarios where this is going to be used. One of the examples cited is that authors at big sites could prepare themes so that their users can selectively do and undo the site settings. But how many users are there that actually need this? Power users will skip the site code and do it all in their own .emacs file. Newbies will rely on the site code. In the few cases, where more choice is involved, big sites have already done the correct thing: They offer a collection of functions that users can call from their .emacs to selectively install parts of the site configuration. If this is the only benefit, 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. Now let us look at another problem. For example my problem : A color theme package. What is the requirement? People want to call a function that sets lots of faces and variables. People might want to undo this once or twice. Well, using the existing custom machinery, I was able to implement this easily! Problem solved! People do not want to do fancy stuff with themes. Just setting the variables is enough. And even simple undoing the settings is possible, because we have the normal custom stuff in place. Sure, this does not solve the problem of people installing themes A, B, and C, and then undoing the settings of B. What settings should be used now? Something equivalent to installing only A and C. But do users really want this? My claim is that they do not. cus-theme.el is going for the perfect solution, but nobody needs it enough to fix it. This holds, eventhough there is very little fixing to do. When I finished porting the code, it worked. All I asked for was some testing, and for some feedback for the alist customizing (I called them diff-lists at the time). It does not even matter wether Dave Love looked at the code or not -- nobody ever asked about it anyway! Thus I conclude that nobody is suffering from a problem. Note that the totally perfect solution would use cus-theme.el, and implemented some UI for theme authors. Currently nobody seems to have such ideas. I faintly remember that I used a widget for simple theme creation at the time. But nobody tested that, either. And guess what? My color-theme.el provides a possibility to save a snapshot of the current configuration. Thus M-x customize-faces suddenly is the interface to produce new themes. What else could a user possibly want. So not even that is really needed. Thus here is my opinion on the cus-theme.el efforts: Implementing the perfect solution took effort (cus-theme.el, my simple make-theme.el), still is not finished (a more elaborate UI might be required, real testing), is not required for power users, is not required for newbies, does not help site administrators, does not improve the color-theme.el experience, is not asked for in the newsgroups. "As far as I am concerned, these last years have shown that there is just no need for that." Alex.