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 themes Date: Tue, 28 Jun 2005 09:41:37 -0500 (CDT) Message-ID: <200506281441.j5SEfba23972@raven.dms.auburn.edu> References: <200506250127.j5P1RWJ11778@raven.dms.auburn.edu> <871x6nytam.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1119970111 25952 80.91.229.2 (28 Jun 2005 14:48:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2005 14:48:31 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 28 16:48:30 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DnHNS-0004bX-44 for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 16:47:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnHVJ-0002QF-Fe for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 10:56:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DnHSS-0001aS-J2 for emacs-devel@gnu.org; Tue, 28 Jun 2005 10:53:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DnHSJ-0001Ws-3C for emacs-devel@gnu.org; Tue, 28 Jun 2005 10:53:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnHSG-0001Qt-7J for emacs-devel@gnu.org; Tue, 28 Jun 2005 10:52:53 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DnHNa-0003XH-1N; Tue, 28 Jun 2005 10:48:02 -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 j5SEhPCK021104; Tue, 28 Jun 2005 09:43:25 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j5SEfba23972; Tue, 28 Jun 2005 09:41:37 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: <871x6nytam.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Tue, 28 Jun 2005 00:57:30 -0400) 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:39789 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39789 Stefan Monnier wrote: > So it might seem too early to document them in the Emacs manual. I think the main reason why they're unused is that they're completely undocumented. I'd love to see some rough documentation for it. In the patches I sent, I provided documentation in the buffers created by `custom-create-theme'. If people decide that after my patches it works reliably enough for their purposes to be ready to be documented in the Emacs manual, I could document it there. Probably most people will only test my patches _after_ they are applied, so I would propose to apply them rather soon. I will at least wait until Richard has had time to comment. It will hopefully help us all better understand the feature and improve it (especially the UI part). I believe my patches add some improvement to the UI part. But I believe that there also is the problem of bugs in the basic code. I think even a somewhat incorrect documentation would be a good thing because it would hopefully give us bug-reports that'll help us improve both the code and the doc. The bugs seem numerous and the basic philosophy behind Custom Themes is not clear. I believe that the present code is the result of two people _independently_ porting XEmacs code. The result looks like three superimposed implementation philosophies fighting with each other. In the text accompanying my patch, I pointed out two bugs remaining after my patches. I can easily fix at least one of the two, but not without adding a fourth conflicting implementation philosophy, which I want to avoid. I only fixed the bugs I believed I could fix without doing that. I do not understand at all the philosophy behind using a `require' type interface to adding themes rather than an unconditional load type philosophy. If I had to implement themes from scratch, my philosophy would be that if two loaded themes conflict, then the most recently added one takes precedence. If you remove the most recently added theme, then the theme added just before that one becomes "top dog". This would seem simple and intuitive. This requires unconditional loading as the basic theme adding operation. But the current code desperately seems to want to implement something else. I have no idea why or what the "something else" could possibly be. I do not use XEmacs and I do not know whether the XEmacs version is actually in active use and works according to some consistent philosophy. I do not know how important compatibility with XEmacs in the Emacs Custom Themes implementation. My patches mainly improve the UI. They avoid touching the basic implementation philosophy (which I do not understand, assuming there is one). Hence, they can not fix the bugs in that implementation. Sincerely, Luc.