Re: Improving Emacs for writing code

[Stefan Monnier]

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


        Stefan