[Top][All Lists]

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


From: klaus.berndl
Subject: RE: ECB
Date: Tue, 7 Mar 2006 14:48:10 +0100


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

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

Any suggestions?

Thanks a lot in advance!


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.   

reply via email to

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