From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "T. V. Raman" Newsgroups: gmane.emacs.devel Subject: Re: Things I would like to be added after the release Date: Fri, 15 Jun 2007 22:01:26 -0700 Message-ID: <18035.28326.988640.435412@gargle.gargle.HOWL> References: <86fy5ghs0s.fsf@lola.quinscape.zz> Reply-To: raman@users.sf.net NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1181970098 12511 80.91.229.12 (16 Jun 2007 05:01:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2007 05:01:38 +0000 (UTC) Cc: emacs-devel@gnu.org, joakim@verona.se, klaus.berndl@sdm.de To: dak@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 16 07:01:37 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 1HzQPo-00039e-Nv for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2007 07:01:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzQPo-0005oQ-Az for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2007 01:01:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzQPj-0005oL-Lx for emacs-devel@gnu.org; Sat, 16 Jun 2007 01:01:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzQPi-0005o9-LV for emacs-devel@gnu.org; Sat, 16 Jun 2007 01:01:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzQPi-0005o6-Bb for emacs-devel@gnu.org; Sat, 16 Jun 2007 01:01:30 -0400 Original-Received: from sccrmhc12.comcast.net ([63.240.77.82]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HzQPg-0003m8-RU; Sat, 16 Jun 2007 01:01:28 -0400 Original-Received: from localhost (c-71-202-191-236.hsd1.ca.comcast.net[71.202.191.236]) by comcast.net (sccrmhc12) with ESMTP id <2007061605012701200g9kjme>; Sat, 16 Jun 2007 05:01:27 +0000 Original-Received: by localhost (Postfix, from userid 1000) id 108EC12A4529; Fri, 15 Jun 2007 22:01:27 -0700 (PDT) In-Reply-To: <86fy5ghs0s.fsf@lola.quinscape.zz> X-Mailer: VM alpha-457 under Emacs 22.1.50.10 (i686-pc-linux-gnu) x-attribution: tvr X-detected-kernel: NetCache Data OnTap 5.x 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:73045 Archived-At: Rather than asking "how can ECB be written to not use advice" here is one way to think of the issue: 0) ECB works fine as is with advice. 1) aAdvice is an interesting implementation technique for identifying extension points and hooks. Said differently, the ecb authors probably used advice because Emacs' builtin hook facilities didn't provide the extension facilities they needed. 2) Assuming you believe (at least partially) (1) above, then rather than asking "how can we rewrite ECB without advice", ask the following alternative question: 3) By observing what extension points ECB needed, what hooks/extension points can base Emacs provide? What can we learn? Which of the ECB extension points are ECB specific, and which aren't? 4) Having answered (3), sensibily add extension points /hooks to Emacs to obviate those advice fragments that were deemed to 5) Leave the issue of whether ECB is implemented with advice or something else to the ECB implementors. have identified generic extension points in (3). >>>>> "David" == David Kastrup writes: David> 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 ;-) David> David> Yes and no. The usual approach here is where a David> package is being actively maintained upstream to let David> the maintainers do their job: the important thing is David> that those working on the package are not hampered. David> XEmacs is, after all, free software. When a package David> is basically only maintained inside of Emacs CVS and David> no-one has a good grip on whether the XEmacs David> compatibility code actually works or fulfills a David> purpose, at some point of time it can be sanest to David> just rip it out. David> David> However, for the sake of readability, it may be a good David> idea to factor out functions differing among Emacsen David> and put them into files of their own. In this case it David> may be possible to leave out the XEmacs specific David> compatibility file from the Emacs CVS, and possibly David> also omit the test and load for it (with the file David> missing, it becomes pointless). In that manner, stuff David> can be developed more or less cleanly. David> David> What I actually consider more of a problem is David> backwards compatibility: if you have a large amount of David> advice, one wants to boil this down into core David> functionality placed into Emacs. This "boiling down" David> may be hard to do when at the same time the goal to David> maintain a version working with older Emacs variants David> (Emacs 22, most likely) remains a priority. David> David> -- David Kastrup David> David> David> _______________________________________________ David> Emacs-devel mailing list Emacs-devel@gnu.org David> http://lists.gnu.org/mailman/listinfo/emacs-devel -- Best Regards, --raman Email: raman@users.sf.net WWW: http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk: tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman IRC: irc://irc.freenode.net/#emacs