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 20:37:01 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <87ofbmomnm.fsf@emacswiki.org> 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 1030559780 21426 127.0.0.1 (28 Aug 2002 18:36:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 28 Aug 2002 18:36:20 +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 17k7fr-0005ZF-00 for ; Wed, 28 Aug 2002 20:36:15 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17k8Bm-0003HG-00 for ; Wed, 28 Aug 2002 21:09:14 +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 17k7hD-00010V-00; Wed, 28 Aug 2002 14:37:39 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17k7ep-0000xf-00 for emacs-devel@gnu.org; Wed, 28 Aug 2002 14:35:11 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17k7en-0000xH-00 for emacs-devel@gnu.org; Wed, 28 Aug 2002 14:35:11 -0400 Original-Received: from relay01.cablecom.net ([62.2.33.101]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17k7em-0000x5-00 for emacs-devel@gnu.org; Wed, 28 Aug 2002 14:35:09 -0400 Original-Received: from smtp.swissonline.ch (mail-4.swissonline.ch [62.2.32.85]) by relay01.cablecom.net (8.12.5/8.12.5/SOL/AWF/MXRELAY/20020820) with ESMTP id g7SIZ720035444 for ; Wed, 28 Aug 2002 20:35:08 +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 g7SIZ7H01530 for ; Wed, 28 Aug 2002 20:35:07 +0200 (MEST) Original-Received: from alex by confusibombus with local (Exim 3.35 #1 (Debian)) id 17k7gb-0000A5-00 for ; Wed, 28 Aug 2002 20:37:01 +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 "Wed, 28 Aug 2002 16:37:16 +0200") Original-Lines: 87 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:7073 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7073 Per Abrahamsen writes: > 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". I had a very simple UI that would allow me to 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. It was trivial. > 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. 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. > 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. Sure -- but do we need the real theme code, with precedences, selective uninstalling, etc? Would a bunch of setq not do the job? You think it would not, I think it would. I don't think we can decide that at the moment. The only thing I know is that I have not seen any requests for it, in the limited time I spend on the newsgroups these days. > 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. Then individual settings will still overwrite stuff installed via startup-requires. > I don't think you can scale the experience gained from the existence > of an unbundled package, to themes being integrated in Emacs. Well, if I cannot generalize it from the existing themes I maintain, who is going to offer an opinion? Nobody else is maintaining anything like it. We could compare it to Gnus group parameters, perhaps. These are also settings saved outside of .emacs and custom. Or the .newsrc.el file. But I find it difficult to draw conclusions from it. It seems to me that my basis for prediction is small, but everybody else's basis is even smaller. > Hopefully, the later will mean many more themes will be available, > with increasing need for conflict resolution and overwriting > individual choises. I'm not sure how conflict resolution will actually improve. I think the user experience will turn out to be something like this: A: Why does this and that not work? B: What themes do you have installed? A: X and Y. B: Ah, these conflict, you must uninstall one of them. A: Oh. If so, then this user experience can be had using my simple idea I offered at the top, using a widget to save setq in files, take advantage of the require/provide conventions, introducing the new option startup-requires, which means adding a bit of code to the place where .emacs is read, and adding a bit of code to the place where customizations are saved. That seems to be far less than the entire cus-theme.el stuff. And I am saying these eventhough I ported Jan's code from XEmacs to Emacs! Alex.