Things I would like to be added after the release

Things I would like to be added after the release

[joakim]

Here is a small wishlist of packages I would like to see added to
emacs core after the release, and after multi-tty and unicode2 are
merged:

- CEDET, the very cool development tools that include on the fly
  language parser called "Semantic" etc.

- ECB, the Emacs Code Browser, which is a client of Semantic

- A css mode

- nxml

- A memory usage viewer like memory-usage.el

... And many more of course. But IMHO it would be nice if focus on new
additions would be to make Emacs a competetive plattform for writing Free
Software in a collaborative manner.

-- 
Joakim Verona

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

[Richard Stallman]

It would be nice to get CEDET and ECB included, but that is a big job.
People need to (1) study whether these packages are implemented in the
best way to fit naturally into Emacs, then (2) change whatever
neds changing to make that so, then (3) get legal papers from
everyone involved.

Would people like to start on these tasks?

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

[joakim]

Richard Stallman <rms@gnu.org> writes:

> It would be nice to get CEDET and ECB included, but that is a big job.
> People need to (1) study whether these packages are implemented in the
> best way to fit naturally into Emacs, then (2) change whatever
> neds changing to make that so, then (3) get legal papers from

Cedet is legally ready to be included in emacs acording to Eric
Ludlam. Some parts, such as the speedbar, already are.

If you enable all the Cedet features at the same time, some
emacs users will be confused, possibly even annoyed. So my strategy
would be to just include cedet in the emacs core, in which case it
does nothing, and then try it out piece by piece.

ECB might require more attention since its written with a lot of
defadvice. Again I would propose simply merging this package(after
Cedet) and take care of the defadvices one by one, to see if more
natural emacs facilities can be created.


> everyone involved.
>
> Would people like to start on these tasks?

-- 
Joakim Verona

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

[klaus.berndl]

joakim@verona.se wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
>> It would be nice to get CEDET and ECB included, but that is a big
>> job. People need to (1) study whether these packages are implemented
>> in the best way to fit naturally into Emacs, then (2) change whatever
>> neds changing to make that so, then (3) get legal papers from
> 
> Cedet is legally ready to be included in emacs acording to Eric
> Ludlam. Some parts, such as the speedbar, already are.
> 
> If you enable all the Cedet features at the same time, some
> emacs users will be confused, possibly even annoyed. So my strategy
> would be to just include cedet in the emacs core, in which case it
> does nothing, and then try it out piece by piece.
> 
> ECB might require more attention since its written with a lot of
> defadvice. Again I would propose simply merging this package(after
> Cedet) and take care of the defadvices one by one, to see if more
> natural emacs facilities can be created.


(3) in Richards list will not be the problem... ;-) - in the other aspects
i agree with Richard, at least concerning ECB (can not speak for cedet)...
we had already a discussion which changes in the Emacs-core would be necessary
to remove a lot of the advices (or at least to code them much more
simple)... most important a new flag on a window-object (similar to the
dedicated-flag) which prevents such a window from being affected by 
window-operations like delete-other-windows etc...

(See a thread called "ECB" in this mailing list from ~ july 2004)

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 ;-)

But then we would have to maintain two ECB-trunks: That one integrated into
Emacs and that one running with both emacs-flavors...

In general i would greatly appreciate if ECB could be integrated into Emacs but
seems really be a big big job...

To get a realistic picture about the necessary code-changing-efforts it would 
help to get a "review" of the code from one of the Emacs-gurus responsible for
Emacs-coding-guidelines and responsible for integrating big packages...
The code is well documented (at least in most cases) and should follow
Emacs coding standards... but its really a huge code-base!

Klaus

> 
> 
>> everyone involved.
>> 
>> Would people like to start on these tasks?

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

[Michael Albinus]

<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 ;-)

I can tell you from the Tramp maintainer's experience: It's not a
problem to keep XEmacs compatibility code. Richard reacts indignant
only if this compatibility code tampers Emacs' functionality.

So far, he has always been right rebuking me :-)

> Klaus

Best regards, Michael.

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

[David Kastrup]

<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 ;-)

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

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

[joakim]

<klaus.berndl@sdm.de> writes:

> joakim@verona.se wrote:
>
> 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 ;-)
>
> But then we would have to maintain two ECB-trunks: That one integrated into
> Emacs and that one running with both emacs-flavors...
>
> In general i would greatly appreciate if ECB could be integrated into Emacs but
> seems really be a big big job...

As far as I've been able to gather from this list, having XEmacs
compatibility code in an Emacs package isnt a problem in principle,
though it might become a maintenance problem.

If ECB is integrated in Emacs, and interfaces between lisp code and
the C core are worked out, the maintenance burden might even become
less because XEmacs might choose to implement the same
interfaces. (Ok, this is naive optimism, but this list might benefit
from some of that :)

> To get a realistic picture about the necessary code-changing-efforts it would 
> help to get a "review" of the code from one of the Emacs-gurus responsible for
> Emacs-coding-guidelines and responsible for integrating big packages...
> The code is well documented (at least in most cases) and should follow
> Emacs coding standards... but its really a huge code-base!
>
> Klaus
>
>> 
>> 
>>> everyone involved.
>>> 
>>> Would people like to start on these tasks?

-- 
Joakim Verona
http://www.verona.se

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

[David Kastrup]

joakim@verona.se writes:

> If ECB is integrated in Emacs, and interfaces between lisp code and
> the C core are worked out, the maintenance burden might even become
> less because XEmacs might choose to implement the same
> interfaces. (Ok, this is naive optimism, but this list might benefit
> from some of that :)

In my impression, the vetting process for Emacs is quite more
strenuous.  In addition, the XEmacs project has few problems synching
to Emacs when they consider the implementation reasonable.  In
contrast, if interfaces are designed and implemented by XEmacs
developers, the legal perspective alone makes it more complicated
getting that code into Emacs.

So the process of getting rid of the advice in lieu of getting
appropriate functionality might lead to fewer incompatibilities and
pains when it is started for Emacs (keeping XEmacs in mind where
necessary) rather than the other way round.

-- 
David Kastrup

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

[Richard Stallman]

    simple)... most important a new flag on a window-object (similar to the
    dedicated-flag) which prevents such a window from being affected by 
    window-operations like delete-other-windows etc...

Would someone like to implement this new feature?

    But here is (4): Currently ECB contains a lot of compatibility-code so
    ECB runs as best as possible with Emacs and XEmacs...

I don't object to compatibility code.  I want it to be done
in a clean and unobtrusive way.

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

[Richard Stallman]

    ECB might require more attention since its written with a lot of
    defadvice. Again I would propose simply merging this package(after
    Cedet) and take care of the defadvices one by one, to see if more
    natural emacs facilities can be created.

I am against that approach, because chances are people would not
actually try hard to remove the defadvices once the program is
included in Emacs.  I would like people to work on removing them
_first_.

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

[Richard Stallman]

    Cedet is legally ready to be included in emacs acording to Eric
    Ludlam. Some parts, such as the speedbar, already are.

    If you enable all the Cedet features at the same time, some
    emacs users will be confused, possibly even annoyed. So my strategy
    would be to just include cedet in the emacs core, in which case it
    does nothing, and then try it out piece by piece.

I think we need to look at Cedet piece by piece, to make sure
each piece is ready for installation.

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

[T. V. Raman]

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

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

[Richard Stallman]

    0)   ECB works fine as is with advice.

ECB is currently an add-on, distributed separately from Emacs.
If we install it, it will be a part of Emacs.

It is bad design to use advice _within_ Emacs.  Advice is a kind of
"come from" construct, and such constructs are very bad for clarity of
a large program.

A few years ago, some programs were installed that contain advice, and
that is a problem.  We need to fix these problems, not add more of
them.  Thus, to install ECB, we need to rewrite the parts that use
advice, make them use other mechanisms.

For instance, we can put the code (or explicit calls to it) into the
functions which currently are advised by ECB.  That is not perfectly
elegant, but it is better than using advice.

This means instead of

(defadvice foo ...)

we have

(defun ecb-foo-extension ...)

and we put an explicit conditional call to ecb-foo-extension
into the definition of foo.

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

[T. V. Raman]

Time will tell, but I believe the form of exntension envisioned
here will make Emacs' codebase less maintainable over time -- 
that is just a personal opini

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     0) ECB works fine as is with advice.  ECB is
    Richard> currently an add-on, distributed separately from
    Richard> Emacs.  If we install it, it will be a part of
    Richard> Emacs.
    Richard> 
    Richard> It is bad design to use advice _within_ Emacs.
    Richard> Advice is a kind of "come from" construct, and such
    Richard> constructs are very bad for clarity of a large
    Richard> program.
    Richard> 
    Richard> A few years ago, some programs were installed that
    Richard> contain advice, and that is a problem.  We need to
    Richard> fix these problems, not add more of them.  Thus, to
    Richard> install ECB, we need to rewrite the parts that use
    Richard> advice, make them use other mechanisms.
    Richard> 
    Richard> For instance, we can put the code (or explicit calls
    Richard> to it) into the functions which currently are
    Richard> advised by ECB.  That is not perfectly elegant, but
    Richard> it is better than using advice.
    Richard> 
    Richard> This means instead of
    Richard> 
    Richard> (defadvice foo ...)
    Richard> 
    Richard> we have
    Richard> 
    Richard> (defun ecb-foo-extension ...)
    Richard> 
    Richard> and we put an explicit conditional call to
    Richard> ecb-foo-extension into the definition of foo.

-- 
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

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

[Miles Bader]

"T. V. Raman" <raman@users.sf.net> writes:
> Time will tell, but I believe the form of exntension envisioned
> here will make Emacs' codebase less maintainable over time -- 
> that is just a personal opinion

Less maintainable than random defadvices all over the place?!?!

I think if you want anybody to take that opinion seriously, you'll have
to support it a bit...

-miles
-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?

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

[Richard Stallman]

    Time will tell, but I believe the form of exntension envisioned
    here will make Emacs' codebase less maintainable over time -- 

It is just the opposite.  Use of advice makes maintenance difficult.
Practically speaking, if a function has advice, then to change the
function you need to study and maybe change the advice too.  This is
easier if the code is integrated into the function.

Even worse, you may not even know the advice exists, and you may
not think of looking.

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

[Stefan Monnier]

> 0)   ECB works fine as is with advice.
> 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? 

That's exactly what is usually meant by "don't use advice in Emacs".
Basically any use of defadvice is either an indication that the programmer
didn't know about some other way to do the thing, or an indication that
there is a missing hook (or config/extension point).

But it can be difficult for Emacs authors to study some external library to
try and understand what hook/extension would be desired.  So it's a lot
better if the library's maintainer helps us coming up with the right
extension point.


        Stefan

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

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 0)   ECB works fine as is with advice.
>> 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? 
>
> That's exactly what is usually meant by "don't use advice in Emacs".
> Basically any use of defadvice is either an indication that the programmer
> didn't know about some other way to do the thing, or an indication that
> there is a missing hook (or config/extension point).
>
> But it can be difficult for Emacs authors to study some external library to
> try and understand what hook/extension would be desired.  So it's a lot
> better if the library's maintainer helps us coming up with the right
> extension point.
>
>
>         Stefan

I did a quick grep on defadvice on ECB below.
Disclaimer: I'm not involved in ECB development, other than as a user.



./ecb-eshell.el:141:(defadvice eshell (around ecb)
./ecb-create-layout.el:237:(defadvice delete-frame (before ecb-create-layout)
./ecb-create-layout.el:246:(defadvice delete-frame (after ecb-create-layout)
./ecb-compatibility.el:63:(defadvice bs-show (before ecb)
./ecb-compatibility.el:77:(defadvice Electric-pop-up-window (around ecb)
./ecb-compatibility.el:95:(defadvice electric-command-history (before ecb)
./ecb-compatibility.el:102:(defadvice electric-buffer-list (before ecb)
./ecb-compatibility.el:109:(defadvice electric-buffer-list (after ecb)
./ecb.texi:10792:(defadvice vc-checkin (after ecb)
./ecb.texi:13885:(defadvice XXX (before ecb activate)
./ecb-winman-support.el:177:(defadvice escreen-save-current-screen-configuration (before ecb)
./ecb-winman-support.el:227:(defadvice winring-set-name (after ecb)
./ecb-winman-support.el:245:(defadvice winring-duplicate-configuration (before ecb)
./ecb-winman-support.el:250:(defadvice winring-restore-configuration (before ecb)
./ecb-winman-support.el:259:(defadvice winring-save-current-configuration (before ecb)
./ecb-winman-support.el:270:(defadvice winring-initialize (after ecb)
./ecb-winman-support.el:293:(defadvice winner-mode (before ecb)
./ecb-winman-support.el:298:(defadvice winner-redo (before ecb)
./ecb-winman-support.el:303:(defadvice winner-undo (before ecb)
./ecb-winman-support.el:309:  (defadvice push-window-configuration (before ecb)
./ecb-winman-support.el:314:  (defadvice pop-window-configuration (before ecb)
./ecb-winman-support.el:319:  (defadvice unpop-window-configuration (before ecb)
./ecb.info-2:2659:        (defadvice vc-checkin (after ecb)
./ecb.info-2:4743:   (defadvice XXX (before ecb activate)
./ecb-speedbar.el:118:(defadvice speedbar-click (around ecb)
./ecb-speedbar.el:141:(defadvice speedbar-frame-mode (around ecb)
./ecb-speedbar.el:149:(defadvice speedbar-get-focus (around ecb)
./ecb-speedbar.el:163:(defadvice dframe-mouse-set-point (around ecb)
./ecb-speedbar.el:184:(defadvice dframe-select-attached-frame (after ecb)
./ecb-util.el:413:(defadvice custom-save-all (around ecb)
./ecb-layout.el:1356:(defadvice delete-frame (around ecb)
./ecb-layout.el:1381:(defadvice compilation-set-window-height (around ecb)
./ecb-layout.el:1432:(defadvice scroll-other-window (around ecb)
./ecb-layout.el:1469:(defadvice scroll-all-mode (after ecb)
./ecb-layout.el:1481:(defadvice count-windows (around ecb)
./ecb-layout.el:1497:(defadvice walk-windows (around ecb)
./ecb-layout.el:1522:(defadvice one-window-p (around ecb)
./ecb-layout.el:1538:;; (defadvice find-file (around ecb)
./ecb-layout.el:1553:;; (defadvice find-file-other-window (around ecb)
./ecb-layout.el:1617: (defadvice show-temp-buffer-in-current-frame (around ecb)
./ecb-layout.el:1657: (defadvice shrink-window-if-larger-than-buffer (around ecb)
./ecb-layout.el:1740: (defadvice pop-to-buffer (around ecb)
./ecb-layout.el:1754: (defadvice mouse-drag-vertical-line (around ecb)
./ecb-layout.el:1765: (defadvice mouse-drag-mode-line (around ecb)
./ecb-layout.el:1777: (defadvice enlarge-window (around ecb)
./ecb-layout.el:1788: (defadvice shrink-window (around ecb)
./ecb-layout.el:1794:            ;; See comment of defadvice for mouse-drag-mode-line
./ecb-layout.el:1804: (defadvice tmm-prompt (around ecb)
./ecb-layout.el:1826: (defadvice shrink-window-if-larger-than-buffer (around ecb)
./ecb-layout.el:1867: (defadvice resize-temp-buffer-window (around ecb)
./ecb-layout.el:1909: (defadvice pop-to-buffer (around ecb)
./ecb-layout.el:2796:(defadvice display-buffer (around ecb)
./ecb-layout.el:3182:(defadvice other-window (around ecb)
./ecb-layout.el:3198:(defadvice delete-windows-on (around ecb)
./ecb-layout.el:3274:(defadvice delete-window (before ecb)
./ecb-layout.el:3303:(defadvice delete-window (around ecb)
./ecb-layout.el:3365:(defadvice delete-other-windows (before ecb)
./ecb-layout.el:3389:(defadvice delete-other-windows (around ecb)
./ecb-layout.el:3453:(defadvice split-window-horizontally (around ecb)
./ecb-layout.el:3474:(defadvice split-window-vertically (around ecb)
./ecb-layout.el:3493:(defadvice split-window (before ecb)
./ecb-layout.el:3520:(defadvice split-window (around ecb)
./ecb-layout.el:3557:(defadvice switch-to-buffer-other-window (around ecb)
./ecb-layout.el:3598:(defadvice switch-to-buffer (around ecb)
./ecb-layout.el:3653:(defadvice other-window-for-scrolling (around ecb)
./ecb-layout.el:3681:(defadvice balance-windows (around ecb)
./ecb-layout.el:4516:(defadvice current-window-configuration (after ecb)
./ecb-layout.el:4551:(defadvice set-window-configuration (after ecb)
./ecb-file-browser.el:2826:(defadvice clearcase-sync-from-disk (after ecb)
./ecb-file-browser.el:3111:(defadvice vc-checkin (after ecb)


-- 
Joakim Verona

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

[T. V. Raman]

well, I would not describe ECB as randomly scattered pieces of
advice, that code base is well organized and cleanly written.

And you could say I'm biased, but I'm also speaking from my own
experience of maintaining a  rather large package that is mostly
built on advice. And using pre/post command hooks to implement it
I believe would have made the codebase impossible to maintain.

>>>>> "Miles" == Miles Bader <miles@gnu.org> writes:
    Miles> "T. V. Raman" <raman@users.sf.net> writes:
    >> Time will tell, but I believe the form of exntension
    >> envisioned here will make Emacs' codebase less
    >> maintainable over time -- that is just a personal opinion
    Miles> 
    Miles> Less maintainable than random defadvices all over the
    Miles> place?!?!
    Miles> 
    Miles> I think if you want anybody to take that opinion
    Miles> seriously, you'll have to support it a bit...
    Miles> 
    Miles> -miles -- Come now, if we were really planning to harm
    Miles> you, would we be waiting here, beside the path, in the
    Miles> very darkest part of the forest?

-- 
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

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

[Nick Roberts]

 > well, I would not describe ECB as randomly scattered pieces of
 > advice, that code base is well organized and cleanly written.
 > 
 > And you could say I'm biased, but I'm also speaking from my own
 > experience of maintaining a  rather large package that is mostly
 > built on advice. And using pre/post command hooks to implement it
 > I believe would have made the codebase impossible to maintain.

I think you're talking of maintaining a package outside of Emacs while
others are talking about doing it _within_ Emacs.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Stephen J. Turnbull]

Nick Roberts writes:

 > T. V. Raman writes

 >> I'm also speaking from my own experience of maintaining a rather
 >> large package that is mostly built on advice. And using pre/post
 >> command hooks to implement it I believe would have made the
 >> codebase impossible to maintain.

 > I think you're talking of maintaining a package outside of Emacs while
 > others are talking about doing it _within_ Emacs.

No, he's talking about using advice rather than hooks.  As we've seen
recently with menu items, callbacks are prone to being implemented as
lambdas which are undocumented except by their source, hard to debug,
and you don't know they are there unless you look specifically at the
hook variable (not the function doc! ... it would be a good idea to
fix that).  By contrast, advice automatically documents that the
function is advised, and automatically displays the docstring that
tells you what changes have been made to behavior.

More fundamentally, advice (as a class of derived function) follows a
stack discipline, and can be read from the outside in, stopping when
you reach a function you fully understand.  By contrast, hooks (again,
as a class) are totally undisciplined; you must read the source of
*all* functions on the hook, you must worry about interactions due to
varying order in different instances, and you must read the source of
the function using the hook to understand it in full.

Of course I'm telling only a partial story here, emphasizing the
advantages of advice over hooks.  But it does have advantages, and
AFAICS the jury is still out on whether those can outweigh the
disadvantages.

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

[Richard Stallman]

    Of course I'm telling only a partial story here, emphasizing the
    advantages of advice over hooks.

The big advantage of a hook, compared with advice, is that there is
something in the caller which informs you that a hook is run there.

It is true that anonymous lambdas as hooks are a pain,
but there's an easy solution to that: give those functions names.

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

[T. V. Raman]

well said.

I still dont quite understand why:

A)      maintaining a package inside Emacs is somehow different
        than maintaining it "outside"

B)      The only advantage to having a package "inside" the emacs
        distrib is user convenience -- should that be offset by
        forcing things like ECB to be rewritten? Feels like that
        time could be more usefully spent writing more Free
        software, rather than writing the same free software
        differently



>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:
    Stephen> Nick Roberts writes:
    >> T. V. Raman writes
    Stephen> 
    >>> I'm also speaking from my own experience of maintaining a
    >>> rather large package that is mostly built on advice. And
    >>> using pre/post command hooks to implement it I believe
    >>> would have made the codebase impossible to maintain.
    Stephen> 
    >> I think you're talking of maintaining a package outside of
    >> Emacs while others are talking about doing it _within_
    >> Emacs.
    Stephen> 
    Stephen> No, he's talking about using advice rather than
    Stephen> hooks.  As we've seen recently with menu items,
    Stephen> callbacks are prone to being implemented as lambdas
    Stephen> which are undocumented except by their source, hard
    Stephen> to debug, and you don't know they are there unless
    Stephen> you look specifically at the hook variable (not the
    Stephen> function doc! ... it would be a good idea to fix
    Stephen> that).  By contrast, advice automatically documents
    Stephen> that the function is advised, and automatically
    Stephen> displays the docstring that tells you what changes
    Stephen> have been made to behavior.
    Stephen> 
    Stephen> More fundamentally, advice (as a class of derived
    Stephen> function) follows a stack discipline, and can be
    Stephen> read from the outside in, stopping when you reach a
    Stephen> function you fully understand.  By contrast, hooks
    Stephen> (again, as a class) are totally undisciplined; you
    Stephen> must read the source of *all* functions on the hook,
    Stephen> you must worry about interactions due to varying
    Stephen> order in different instances, and you must read the
    Stephen> source of the function using the hook to understand
    Stephen> it in full.
    Stephen> 
    Stephen> Of course I'm telling only a partial story here,
    Stephen> emphasizing the advantages of advice over hooks.
    Stephen> But it does have advantages, and AFAICS the jury is
    Stephen> still out on whether those can outweigh the
    Stephen> disadvantages.

-- 
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

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

[Stefan Monnier]

> A)      maintaining a package inside Emacs is somehow different
>         than maintaining it "outside"

Here's my take on it: if I modify function FOO in subr.el which is advised
by package BAR, and my modification breaks BAR, there are 2 possible cases:
1 - BAR is not in Emacs: I get to say "tough!".  I.e. I don't need to know
    or care that some other external package advises FOO.
2 - BAR is in Emacs: I have to figure out that BAR is broken and then I have
    to fix it.

BTW the advantage of hooks here is that when I modify FOO, I get to see that
there's a hook here, so I know I have to be careful to preserve the behavior
of the hook when modifying FOO, since I otherwise risk breaking some other
package using the hook.


        Stefan