[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Improving Emacs for writing code

From: klaus.berndl
Subject: RE: Improving Emacs for writing code
Date: Tue, 22 Apr 2008 18:54:59 +0200

Stefan Monnier wrote:
>> Emacs does a lot of things uniquely well, but we can still learn from
>> other code writing environments how to improve the code writing
>> experience in Emacs.
>> These are concrete proposals I'm prepared to invest time in:
>> - Merge Cedet in Emacs.
>> Cedet provides many facilities necessary to emulate other modern
>> IDE:s, for instance language parsers in lisp. I think Cedet is
>> nicely written, and that it wouldn't be a great problem to merge it
>> if a decision to do it was reached. I've contributed things to the
>> package and I'm prepared to help with any grunt work necessary for
>> the merge, for instance discussing issues from emacs-devel with the
>> packages principal authors. 
> IDE-style features are sorely needed I think, so I am in favor of
> adding such things to Emacs.  I do not know enough about the current
> state of CEDET to know how easy it would be to integrate it. 
> Problems I envision are mostly:
> 1 - Getting the copyright paperwork done: the CEDET project has
>     existed for a long time now, so it likely has had many
>     contributors over the years, making it that much more difficult
>     to get all the relevant paperwork.
> 2 - Making sure CEDET does not affect Emacs globally: last time I
>     tried CEDET (admittedly, several years ago), it had the nasty
>     tendency to "take over Emacs", so I couldn't use it for Java
>     without also having it messing with my Elisp buffers.
>> - Provide some ECB like features in Emacs.
>> ECB provides the typical IDE workspace view in Emacs, but achieves
>> this by advising Emacs core functions a lot.
>> In another thread on this list RMS identified the following core C
>> level features to be implemented for this feature(slightly edited by
>> me): 
>> ---------------
>> Perhaps the cleanest way is to give each window a plist to specify
>> whether various operations should consider it.  It could have a:
>> - `delete-other-windows' property and a
>> - `select-window' property and a
>> - `display-buffer' property, and the values of these properties would
>> control whether those operations can use this window.
>> (this last one can be postponed, since "dedicted" does the same)
>> The new `display-buffer' property could be equivalent to the existing
>> "dedicated" flag.  That would mean it affects some other primitives
>> aside from `display-buffer', but that is ok.  There is no need to be
>> rigid about the relationship between these properties and primitives
>> they affect. ---------------------
>> I'm interested in working on initially implementing the first 2
>> flags in this list. The display-buffer property could be implemented
>> later, since the current "window dedication" feature does the same.
> It is probably a good idea to try out such an implementation.  I'm not
> sure if it will work well, but it is worth a try.  I would like also
> to see some description of the advice used by ECB, to better a better
> idea of what kind of features are needed.  I tried to look at the
> code, but it uses so many pieces of advice, that it's difficult for
> me to 
> get a feel for what they do overall.

>From the maintainer of ECB: I remember these discussions with RMS some time
ago - i agree 100% that it would be great if Emacs could offer some core-
functionality so a lot of the currently needed ECB-advices would become
obsolet... i can try to cluster the advices for you - but in the latest
beta i have restructured all the advice-stuff much more robustly - here is
the related NEWS-section:

** Much saver advice-backbone for all advices needed by ECB

   This is not a user-visible change but enhances the stability of ECB by
   using now a new advice-backbone which guarantes that all ecb-advices are
   enabled rsp. disabled correctly depending on the surrounding context.
   Introducing three new macros `defecb-advice-set', `defecb-advice' and

I have uploaded this 2.33beta1 version as a new CVS-snapshot to ecb.sf.net
(see Download-section)

All advice-sets of ECB are now defined with the macro defecb-advice-set...
For the layout engine the advice-set `ecb-basic-adviced-functions'
is the most important one - here is the value:

((set-window-configuration . after)
 (current-window-configuration . after)
 (balance-windows . around)
 (other-window-for-scrolling . around)
 (switch-to-buffer . around)
 (switch-to-buffer-other-window . around)
 (split-window . around)
 (split-window-vertically . around)
 (split-window-horizontally . around)
 (delete-other-windows . around)
 (delete-window . around)
 (delete-windows-on . around)
 (other-window . around)
 (display-buffer . around)
 (pop-to-buffer . around)
 (resize-temp-buffer-window . around)
 (shrink-window-if-larger-than-buffer . around)
 (shrink-window . around)
 (enlarge-window . around)
 (mouse-drag-mode-line . around)
 (mouse-drag-vertical-line . around)
 (scroll-other-window . around)
 (compilation-set-window-height . around)
 (delete-frame . around))

these are the functions ECB advices for its layout engine and some (lot?)
of these advices can probably be eliminated when Emacs offers the
+mentioned new c-core-functionality (as joakim has described above)
All of the advices are well documented!

But do not hesitate to ask me if you need further explanations or help!
I'm quite busy but i will do my best to support you in understanding
ECB for the sake of integrating it (or some of it's functionality) into


>         Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]