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: Things I would like to be added after the release Date: Tue, 29 May 2007 11:56:51 +0200 Message-ID: <86fy5ghs0s.fsf@lola.quinscape.zz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1180432632 6697 80.91.229.12 (29 May 2007 09:57:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 29 May 2007 09:57:12 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 29 11:57:10 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HsyRv-00013I-3S for ged-emacs-devel@m.gmane.org; Tue, 29 May 2007 11:57:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HsyRu-0003TH-65 for ged-emacs-devel@m.gmane.org; Tue, 29 May 2007 05:57:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HsyRk-0003R8-Rl for emacs-devel@gnu.org; Tue, 29 May 2007 05:56:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HsyRj-0003P5-1r for emacs-devel@gnu.org; Tue, 29 May 2007 05:56:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HsyRi-0003Oe-2l for emacs-devel@gnu.org; Tue, 29 May 2007 05:56:54 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HsyRi-0004F8-1d for emacs-devel@gnu.org; Tue, 29 May 2007 05:56:54 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id LAA16959 for ; Tue, 29 May 2007 11:56:50 +0200 X-Delivered-To: Original-Received: (qmail 21287 invoked from network); 29 May 2007 09:56:51 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 29 May 2007 09:56:51 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id C1CAA8F832; Tue, 29 May 2007 11:56:51 +0200 (CEST) In-Reply-To: (klaus berndl's message of "Tue\, 29 May 2007 11\:36\:44 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:71935 Archived-At: writes: > But here is (4): Currently ECB contains a lot of compatibility-code > so ECB runs as best as possible with Emacs and XEmacs... this is a > goal of ECB and should remain as a goal. I doubt Richard wants to > have XEmacs- compatibility-code in the ECB integrated in the > Emacs-trunc ;-) Yes and no. The usual approach here is where a package is being actively maintained upstream to let the maintainers do their job: the important thing is that those working on the package are not hampered. XEmacs is, after all, free software. When a package is basically only maintained inside of Emacs CVS and no-one has a good grip on whether the XEmacs compatibility code actually works or fulfills a purpose, at some point of time it can be sanest to just rip it out. However, for the sake of readability, it may be a good idea to factor out functions differing among Emacsen and put them into files of their own. In this case it may be possible to leave out the XEmacs specific compatibility file from the Emacs CVS, and possibly also omit the test and load for it (with the file missing, it becomes pointless). In that manner, stuff can be developed more or less cleanly. What I actually consider more of a problem is backwards compatibility: if you have a large amount of advice, one wants to boil this down into core functionality placed into Emacs. This "boiling down" may be hard to do when at the same time the goal to maintain a version working with older Emacs variants (Emacs 22, most likely) remains a priority. -- David Kastrup