* Things I would like to be added after the release @ 2007-05-28 9:04 joakim 2007-05-29 0:02 ` Richard Stallman 0 siblings, 1 reply; 24+ messages in thread From: joakim @ 2007-05-28 9:04 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-28 9:04 Things I would like to be added after the release joakim @ 2007-05-29 0:02 ` Richard Stallman 2007-05-29 8:02 ` joakim 0 siblings, 1 reply; 24+ messages in thread From: Richard Stallman @ 2007-05-29 0:02 UTC (permalink / raw) To: joakim; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 0:02 ` Richard Stallman @ 2007-05-29 8:02 ` joakim 2007-05-29 9:36 ` klaus.berndl ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: joakim @ 2007-05-29 8:02 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Things I would like to be added after the release 2007-05-29 8:02 ` joakim @ 2007-05-29 9:36 ` klaus.berndl 2007-05-29 9:52 ` Michael Albinus ` (3 more replies) 2007-06-04 0:17 ` Richard Stallman 2007-06-04 0:17 ` Richard Stallman 2 siblings, 4 replies; 24+ messages in thread From: klaus.berndl @ 2007-05-29 9:36 UTC (permalink / raw) To: joakim, emacs-devel 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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 9:36 ` klaus.berndl @ 2007-05-29 9:52 ` Michael Albinus 2007-05-29 9:56 ` David Kastrup ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: Michael Albinus @ 2007-05-29 9:52 UTC (permalink / raw) To: klaus.berndl; +Cc: joakim, emacs-devel <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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 9:36 ` klaus.berndl 2007-05-29 9:52 ` Michael Albinus @ 2007-05-29 9:56 ` David Kastrup 2007-06-16 5:01 ` T. V. Raman 2007-05-29 10:02 ` joakim 2007-06-02 2:54 ` Richard Stallman 3 siblings, 1 reply; 24+ messages in thread From: David Kastrup @ 2007-05-29 9:56 UTC (permalink / raw) To: klaus.berndl; +Cc: joakim, emacs-devel <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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 9:56 ` David Kastrup @ 2007-06-16 5:01 ` T. V. Raman 2007-06-16 18:50 ` Richard Stallman 2007-06-17 12:47 ` Stefan Monnier 0 siblings, 2 replies; 24+ messages in thread From: T. V. Raman @ 2007-06-16 5:01 UTC (permalink / raw) To: dak; +Cc: emacs-devel, joakim, klaus.berndl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-16 5:01 ` T. V. Raman @ 2007-06-16 18:50 ` Richard Stallman 2007-06-16 23:37 ` T. V. Raman 2007-06-17 12:47 ` Stefan Monnier 1 sibling, 1 reply; 24+ messages in thread From: Richard Stallman @ 2007-06-16 18:50 UTC (permalink / raw) To: raman; +Cc: klaus.berndl, joakim, emacs-devel 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-16 18:50 ` Richard Stallman @ 2007-06-16 23:37 ` T. V. Raman 2007-06-16 23:50 ` Miles Bader 2007-06-17 8:54 ` Richard Stallman 0 siblings, 2 replies; 24+ messages in thread From: T. V. Raman @ 2007-06-16 23:37 UTC (permalink / raw) To: rms; +Cc: raman, klaus.berndl, joakim, emacs-devel 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-16 23:37 ` T. V. Raman @ 2007-06-16 23:50 ` Miles Bader 2007-06-17 18:08 ` T. V. Raman 2007-06-17 8:54 ` Richard Stallman 1 sibling, 1 reply; 24+ messages in thread From: Miles Bader @ 2007-06-16 23:50 UTC (permalink / raw) To: raman; +Cc: emacs-devel, rms, joakim, klaus.berndl "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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-16 23:50 ` Miles Bader @ 2007-06-17 18:08 ` T. V. Raman 2007-06-17 20:15 ` Nick Roberts 0 siblings, 1 reply; 24+ messages in thread From: T. V. Raman @ 2007-06-17 18:08 UTC (permalink / raw) To: miles; +Cc: raman, emacs-devel, rms, joakim, klaus.berndl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-17 18:08 ` T. V. Raman @ 2007-06-17 20:15 ` Nick Roberts 2007-06-18 3:25 ` Stephen J. Turnbull 0 siblings, 1 reply; 24+ messages in thread From: Nick Roberts @ 2007-06-17 20:15 UTC (permalink / raw) To: raman; +Cc: emacs-devel, klaus.berndl, rms, joakim, miles > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-17 20:15 ` Nick Roberts @ 2007-06-18 3:25 ` Stephen J. Turnbull 2007-06-18 21:31 ` Richard Stallman 2007-06-21 7:29 ` T. V. Raman 0 siblings, 2 replies; 24+ messages in thread From: Stephen J. Turnbull @ 2007-06-18 3:25 UTC (permalink / raw) To: Nick Roberts; +Cc: rms, klaus.berndl, joakim, emacs-devel, raman, miles 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-18 3:25 ` Stephen J. Turnbull @ 2007-06-18 21:31 ` Richard Stallman 2007-06-21 7:29 ` T. V. Raman 1 sibling, 0 replies; 24+ messages in thread From: Richard Stallman @ 2007-06-18 21:31 UTC (permalink / raw) To: Stephen J. Turnbull Cc: klaus.berndl, nickrob, joakim, emacs-devel, raman, miles 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-18 3:25 ` Stephen J. Turnbull 2007-06-18 21:31 ` Richard Stallman @ 2007-06-21 7:29 ` T. V. Raman 2007-06-21 8:09 ` Stefan Monnier 1 sibling, 1 reply; 24+ messages in thread From: T. V. Raman @ 2007-06-21 7:29 UTC (permalink / raw) To: stephen; +Cc: rms, klaus.berndl, nickrob, joakim, emacs-devel, raman, miles 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-21 7:29 ` T. V. Raman @ 2007-06-21 8:09 ` Stefan Monnier 0 siblings, 0 replies; 24+ messages in thread From: Stefan Monnier @ 2007-06-21 8:09 UTC (permalink / raw) To: raman Cc: rms, klaus.berndl, nickrob, joakim, emacs-devel, stephen, raman, miles > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-16 23:37 ` T. V. Raman 2007-06-16 23:50 ` Miles Bader @ 2007-06-17 8:54 ` Richard Stallman 1 sibling, 0 replies; 24+ messages in thread From: Richard Stallman @ 2007-06-17 8:54 UTC (permalink / raw) To: raman; +Cc: raman, klaus.berndl, joakim, emacs-devel 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-16 5:01 ` T. V. Raman 2007-06-16 18:50 ` Richard Stallman @ 2007-06-17 12:47 ` Stefan Monnier 2007-06-17 16:00 ` joakim 1 sibling, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2007-06-17 12:47 UTC (permalink / raw) To: raman; +Cc: klaus.berndl, joakim, emacs-devel > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-06-17 12:47 ` Stefan Monnier @ 2007-06-17 16:00 ` joakim 0 siblings, 0 replies; 24+ messages in thread From: joakim @ 2007-06-17 16:00 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 9:36 ` klaus.berndl 2007-05-29 9:52 ` Michael Albinus 2007-05-29 9:56 ` David Kastrup @ 2007-05-29 10:02 ` joakim 2007-05-29 10:16 ` David Kastrup 2007-06-02 2:54 ` Richard Stallman 3 siblings, 1 reply; 24+ messages in thread From: joakim @ 2007-05-29 10:02 UTC (permalink / raw) To: emacs-devel; +Cc: klaus.berndl <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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 10:02 ` joakim @ 2007-05-29 10:16 ` David Kastrup 0 siblings, 0 replies; 24+ messages in thread From: David Kastrup @ 2007-05-29 10:16 UTC (permalink / raw) To: joakim; +Cc: klaus.berndl, emacs-devel 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 9:36 ` klaus.berndl ` (2 preceding siblings ...) 2007-05-29 10:02 ` joakim @ 2007-06-02 2:54 ` Richard Stallman 3 siblings, 0 replies; 24+ messages in thread From: Richard Stallman @ 2007-06-02 2:54 UTC (permalink / raw) To: klaus.berndl; +Cc: joakim, emacs-devel 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 8:02 ` joakim 2007-05-29 9:36 ` klaus.berndl @ 2007-06-04 0:17 ` Richard Stallman 2007-06-04 0:17 ` Richard Stallman 2 siblings, 0 replies; 24+ messages in thread From: Richard Stallman @ 2007-06-04 0:17 UTC (permalink / raw) To: joakim; +Cc: emacs-devel 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_. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Things I would like to be added after the release 2007-05-29 8:02 ` joakim 2007-05-29 9:36 ` klaus.berndl 2007-06-04 0:17 ` Richard Stallman @ 2007-06-04 0:17 ` Richard Stallman 2 siblings, 0 replies; 24+ messages in thread From: Richard Stallman @ 2007-06-04 0:17 UTC (permalink / raw) To: joakim; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2007-06-21 8:09 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-05-28 9:04 Things I would like to be added after the release joakim 2007-05-29 0:02 ` Richard Stallman 2007-05-29 8:02 ` joakim 2007-05-29 9:36 ` klaus.berndl 2007-05-29 9:52 ` Michael Albinus 2007-05-29 9:56 ` David Kastrup 2007-06-16 5:01 ` T. V. Raman 2007-06-16 18:50 ` Richard Stallman 2007-06-16 23:37 ` T. V. Raman 2007-06-16 23:50 ` Miles Bader 2007-06-17 18:08 ` T. V. Raman 2007-06-17 20:15 ` Nick Roberts 2007-06-18 3:25 ` Stephen J. Turnbull 2007-06-18 21:31 ` Richard Stallman 2007-06-21 7:29 ` T. V. Raman 2007-06-21 8:09 ` Stefan Monnier 2007-06-17 8:54 ` Richard Stallman 2007-06-17 12:47 ` Stefan Monnier 2007-06-17 16:00 ` joakim 2007-05-29 10:02 ` joakim 2007-05-29 10:16 ` David Kastrup 2007-06-02 2:54 ` Richard Stallman 2007-06-04 0:17 ` Richard Stallman 2007-06-04 0:17 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).