From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: ECB
Date: Wed, 14 Jul 2004 14:26:08 -0400 [thread overview]
Message-ID: <E1BkoSG-0003pC-CR@fencepost.gnu.org> (raw)
In-Reply-To: <1B3ACCFD5694A94DBA4E231402B0E9ED040976@mucmail1.sdm.de> (klaus.berndl@sdm.de)
>Do you think that this feature should be integrated into Emacs at the
>C level?
Hmm, depends. IMO Emacs is not really designed for having a
window-layout where some windows should be permanent and should
always contain some certain stuff (like the special
ECB-browsing-tree-buffers/windows) and the rest of the windows
which can be deleted and created by the user (like the
editing-area of ECB).
Not now; that's why I'm suggesting to change it.
BTW: If you remember we had already a short discussion about the
adding a mechanism (flag) to the c-level so a window can be marked
to be excluded from delete-other-window... please apologize but i
haven't still found enough time to implement this.
I remembered having that discussion, but not who I had discussed it
with. It sounds like ECB has implemented the same feature (more or
less) at Lisp level. Do you agree that C level would be the best
place to put it?
Example: ECB advices the `display-buffer' so it displays all
"compilation"-buffers (buffers which fulfill criterias a user has
defined so they should be displayed in the compilation-output-window
of ECB) in the compilation-output-window of ECB (an optional but then
permanent window at the bottom of the ecb-frame), all special
ecb-buffers in the assigned ecb-window and for the rest of the buffers
it uses the edit-area of the ecb-frame as if this area would be the
whole frame. Works save and like a charm but needs for this a big and
- i admit - complex advice. So IMHO it would make sense for some
mechanisms (needed by ECB) to be included in the Emacs-core because
IMHO it is always better - regardless of the code-quality and the
saveness of an advive of an internal central function like
display-buffer - to implement this in the emacs-core instead with an
advice.
That's exactly what I think. In fact, we want to avoid defining any
advice in Emacs itself.
The question is if it should be at the c-level
or at the lisp-level?
It should be implemented within display-buffer, which means, in C
level.
To rewrite display-buffer in Lisp is a separate idea. I'm not against
it, if someone wants to do it. Not right now; now our focus is on getting
a release to work. But if you want to do that, it would be ok, and
we could install that just before installing ECB.
next prev parent reply other threads:[~2004-07-14 18:26 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-13 12:42 ECB Berndl, Klaus
2004-07-14 18:26 ` Richard Stallman [this message]
2004-07-14 18:27 ` ECB Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2006-03-08 9:50 ECB klaus.berndl
2006-03-08 14:54 ` ECB Stefan Monnier
2006-03-08 15:08 ` ECB Drew Adams
2006-03-09 4:44 ` ECB Miles Bader
2006-03-08 22:18 ` ECB Eli Zaretskii
2006-03-09 16:04 ` ECB Stefan Monnier
2006-03-09 19:59 ` ECB Eli Zaretskii
2006-03-11 22:05 ` ECB Juri Linkov
2006-03-08 9:45 ECB klaus.berndl
2006-03-09 17:13 ` ECB Richard Stallman
2006-03-07 17:01 ECB klaus.berndl
2006-03-08 4:22 ` ECB Richard Stallman
2006-03-07 13:48 ECB klaus.berndl
2006-03-07 16:48 ` ECB Stefan Monnier
2006-03-08 4:21 ` ECB Richard Stallman
2004-07-07 16:57 ECB Berndl, Klaus
2004-07-07 20:50 ` ECB Jérôme Marant
2004-07-07 16:54 ECB Berndl, Klaus
2004-07-08 23:18 ` ECB Richard Stallman
2004-07-11 23:24 ` ECB Richard Stallman
2004-07-07 16:47 ECB Berndl, Klaus
[not found] <E1Bgmxo-0006Bh-0o@monty-python.gnu.org>
2004-07-05 12:06 ` ECB Eric M. Ludlam
2004-07-05 12:53 ` ECB Stefan
[not found] ` <E1BhoWE-0004n3-7k@fencepost.gnu.org>
[not found] ` <200407061241.i66CfX1w016798@projectile.siege-engine.com>
2004-07-12 23:58 ` ECB Richard Stallman
2004-07-02 17:51 ECB Richard Stallman
2004-07-02 18:10 ` ECB Jason Rumney
2004-07-02 20:29 ` ECB Jérôme Marant
2004-07-03 18:21 ` ECB Richard Stallman
2004-07-03 21:56 ` ECB Jason Rumney
2004-07-05 14:23 ` ECB Richard Stallman
2004-07-06 1:29 ` ECB Miles Bader
2004-07-06 7:41 ` ECB Jason Rumney
2004-07-06 21:59 ` ECB Richard Stallman
2004-07-03 15:22 ` ECB Kai Grossjohann
2004-07-03 17:05 ` ECB Stefan
2004-07-04 2:13 ` ECB Richard Stallman
2004-07-04 9:38 ` ECB Kai Grossjohann
2004-07-04 10:24 ` ECB Jason Rumney
2004-07-04 12:01 ` ECB Jens Lautenbacher
2003-01-23 14:06 ECB Dr. F.C.Caner
2003-01-23 15:36 ` ECB Klaus Berndl
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1BkoSG-0003pC-CR@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.