From: <klaus.berndl@sdm.de>
To: <monnier@iro.umontreal.ca>, <joakim@verona.se>
Cc: emacs-devel@gnu.org
Subject: RE: Improving Emacs for writing code
Date: Tue, 22 Apr 2008 18:54:59 +0200 [thread overview]
Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E33A8D20@mucmail3.sdm.de> (raw)
In-Reply-To: <jwv1w4x51q2.fsf-monnier+emacs@gnu.org>
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
`ecb-with-original-adviced-function-set'.
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
Emacs...
Klaus
>
>
> Stefan
next prev parent reply other threads:[~2008-04-22 16:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 10:06 Improving Emacs for writing code joakim
2008-04-22 15:49 ` David Hansen
2008-04-22 21:49 ` Re[2]: " Eric M. Ludlam
2008-04-23 1:33 ` Stefan Monnier
2008-04-23 5:10 ` Chong Yidong
2008-04-23 14:05 ` Re[2]: " Eric M. Ludlam
2008-04-23 14:23 ` Chong Yidong
2008-04-23 17:29 ` Stefan Monnier
2008-04-23 15:00 ` Re[2]: " Eric M. Ludlam
2008-04-23 17:45 ` Stefan Monnier
2008-04-24 2:41 ` Re[2]: " Eric M. Ludlam
2008-04-23 19:05 ` Richard M Stallman
2008-04-22 16:02 ` Stefan Monnier
2008-04-22 16:54 ` klaus.berndl [this message]
2008-04-22 17:07 ` Lennart Borgman (gmail)
2008-04-23 8:26 ` klaus.berndl
2008-04-23 10:26 ` Nick Roberts
2008-04-23 11:59 ` klaus.berndl
2008-04-23 13:00 ` Nick Roberts
2008-04-23 12:12 ` Neal Becker
2008-04-23 12:19 ` klaus.berndl
2008-04-23 12:28 ` Neal Becker
2008-04-23 21:34 ` Stephen J. Turnbull
2008-04-22 20:08 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84D8FEFE8D23E94E9C2A6F0C58EE07E33A8D20@mucmail3.sdm.de \
--to=klaus.berndl@sdm.de \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).