From: <klaus.berndl@sdm.de>
Cc: emacs-devel@gnu.org
Subject: RE: ECB
Date: Tue, 7 Mar 2006 14:48:10 +0100 [thread overview]
Message-ID: <A47B192B0358794C958615D788BF7FB701A29E95@mucmail1.sdm.de> (raw)
Hello,
Sorry for reactivating such an old thread but the latest cvs-Emacs pops this
up for me:
I saw, that balance-window has been completely reimplemented on base of
a new c-level-function `window-tree'...fine, but:
Tools like ECB makes a lot of handstands to exclude some windows (the
special ECB-windows which display stuff like dirs, files and file-
contents from being deleted by command like delete-other-windows etc...
Or in general: To exclude these special ECB-windos from being taken into
account in general (e.g. also by count-windows, walk-windows in special
situations).
This is done by advices which are save and only active when ECB is active...
Richard, do you remember this thread - see below?
We had discussed how to prevent some special windows from being deleted?
Now i think we would need a more general mechanism which would also prevent
such windows from being included in the tree returned by `window-tree' so
all features based on new `window-tree' (AFAIK currently only `balance-window')
can ignore this window from their doing....
I think this is not necessary for the current Emacs-release but a least then, when
ECB should be integrated into Emacs (at least if this is intended ;-)
But for now: Are there some work-arounds possible how to exclude some windows
from being "balanced" (means ajusted) by the new balance-window?
In the old one an advice for `walk-windows' was enough which simply does not
walk through these special windows... But now, `walk-windows' is not used but
`window-tree'...
Any suggestions?
Thanks a lot in advance!
Ciao,
klaus
Richard Stallman wrote:
> >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 reply other threads:[~2006-03-07 13:48 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-07 13:48 klaus.berndl [this message]
2006-03-07 16:48 ` ECB Stefan Monnier
2006-03-08 4:21 ` 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
2004-07-13 12:42 ECB Berndl, Klaus
2004-07-14 18:26 ` ECB Richard Stallman
2004-07-14 18:27 ` 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=A47B192B0358794C958615D788BF7FB701A29E95@mucmail1.sdm.de \
--to=klaus.berndl@sdm.de \
--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.