Re: Things I would like to be added after the release

["T. V. Raman" <raman@users.sf.net>]

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
     <dak@gnu.org> writes: David> <klaus.berndl@sdm.de> 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