From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: theming Date: Thu, 07 Jul 2005 16:20:35 +0200 Message-ID: <85pstun1e4.fsf@lola.goethe.zz> References: <42CC7021.5050606@student.lu.se> <42CCD07F.5010509@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1120823362 3819 80.91.229.2 (8 Jul 2005 11:49:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Jul 2005 11:49:22 +0000 (UTC) Cc: "John S. Yates, Jr." , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 08 13:49:13 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DqrLl-0002Oi-Uc for ged-emacs-devel@m.gmane.org; Fri, 08 Jul 2005 13:48:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqrNB-00044X-5t for ged-emacs-devel@m.gmane.org; Fri, 08 Jul 2005 07:50:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DqrEl-0001xJ-A8 for emacs-devel@gnu.org; Fri, 08 Jul 2005 07:41:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DqrEi-0001vw-SF for emacs-devel@gnu.org; Fri, 08 Jul 2005 07:41:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqrEi-0001up-5J for emacs-devel@gnu.org; Fri, 08 Jul 2005 07:41:40 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DqrIg-0003Yh-Pk for emacs-devel@gnu.org; Fri, 08 Jul 2005 07:45:46 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Dqr9U-0006NU-Ob; Fri, 08 Jul 2005 07:36:16 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 052111CE0FE5; Thu, 7 Jul 2005 16:20:35 +0200 (CEST) Original-To: David Reitter In-Reply-To: (David Reitter's message of "Thu, 7 Jul 2005 13:22:05 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:40639 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40639 David Reitter writes: > I have implemented the single frame behavior (it takes more than > OneonOne to do that), for example. > And if I understand correctly what themes are supposed to do, I > cannot but agree with you that the currently planned collections of > customization settings won't do the job for efforts to change the > user interface (point 2 below). Themes make some headway though > (point 1): > > 1. Aquamacs changes a lot of default customization settings, and it > also ensures that the user's actual customizations are noted as > such and saved - by setting the 'standard-value property whenever > a customization variable is set. That way we ensure that the user > can still customize whatever - it's just the defaults that are > changed. A lot of hooks are used, but they could be handled as > customization variables. > Making this process a bit easier, making it easier for the user to > undo some of these new 'defaults' by defining groups of > customizations in themes would certainly be desirable. > > 2. However, over the last two or three months or so, Aquamacs has > come to do much more than that. It blatantly redefines and advises > functions, something which can only be undone by means of extra > customization variables that are checked by the new functions. Those customization variables can have a default value that lets them cause different behavior only when under the Aquamacs theme. So I don't see this as a principal problem once themes work properly. > In addition to that, we patch the c core and one or two of the .el > files in order to either implement needed additional functionality > or (on the Carbon port side) to modify functionality. In addition to > that, several support files in the original package are modified, > others added (converted manuals). [I make an effort to contribute > changes, in particular bugfixes, where I see fit - it's not a > competing fork.] It is a competing fork in the manner that users are not able to make it work like standard Emacs with minimal effort. That means that the Aquamacs distribution is only useful for people that don't prefer standard Emacs behavior. That's not a good state of affairs. If Aquamacs were theme-controlled, one could easily fold the whole kaboodle back into the main core, and thus people, say, used to Aquamacs could get the same behavior under Windows, and there would be no reason to distribute competing binaries for MacOSX. > CONCLUSION: > We cannot realize your points with collections of customization > settings. The changes are much more profound. I still don't see what would prohibit those changes from being folded back into Emacs once they are properly controlled by a theme. > Therefore, there is another consideration that becomes more > important: Makers of a distribution like Aquamacs would really need > a stable, relatively bug-free release. We're shooting at a moving > target otherwise. With regard to theme support, fixing the target right now seems incompatible with both stable (as it would need to get changed afterwards, anyway) and relatively bug-free. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum