Re: patch for optional inhibit of delete-other-windows(IDE feature)

[martin rudalics]

> By setting `temp-buffer-show-function' to the following ecb-function
> which does this.

I see.  Maybe we could introduce an option which makes temporary buffers
always appear in a window on the bottom of the frame, technically spoken
in a subwindow of the root-window of that frame.  If Emacs can handle
resizing the remaining windows well this wouldn't be very hard.  What
happens when you want to display a compile- and a help-window (or Info
window) appear all at the same time?

> To make a long story short: It would be very very great if there is
> a commitment that *each* command or function which has to display
> a buffer in a window uses internaly `display-buffer', because then
> it would probably sufficient for ECB to patch this machanism (either
> by adding a full featured display-buffer-function or by advicing
> display-buffer itself).
>
> What is the current state with this respect?

`switch-to-buffer' surely won't.

> ecb-redraw-layout-full performs all the layouting. For this it does
> all the window-structure-independ stuff out-of-the-box and then it
> calls a special layout-function `ecb-layout-function-<layoutname>'
> which performs all the splits necessary for a certain layout...

We can't do this in window.c.  We would have to be able to get the
current layout independently from how it was obtained in the first
place.

> another topic: ECB automatically stores all split-window-* calls
> and delete-window and delete-other-windows calls performed in the
> edit-area (this is simply done by before-advices of these commands).
> so after a full redraw ECB "replays" these stored split- and delete-
> commands and voila: the edit-area has the same window-structure
> as before... but it had cost me huge effort to implement this stable.

Plus the perfomance penalty from storing and retrieving this.  We have
to get away from this "operational" (split-/delete-window operations
based) view of the current frame layout.

> It would be very great if the object `save-window-configuration'
> stores would be "readable" or "accessible" in a way so we could
> restore only parts of a frame (in case of ECB the edit-area)...
> Do not know the current state of Emacs with this respect?!

Currently it works for frames only.  We'd have to strip the frame
specific parts (like the visibility, toolbar, menubar settings) which is
easy.  The problem remains _how_ we want to identify the "part of the
frame" (the edit-area in your case).  Technically it is, as I explained
earlier, an internal Emacs window.  We have to expose it to the Elisp
programmer in a convenient way.  For safety reasons I'm against exposing
the internal window directly to Elispers (XEmacs does that).

>>IIUC the first thing we should provide is find a way to (i) squeeze an
>>entire frame into a window and (ii) blow up an internal Emacs window
>>to
>>a frame.  The only problems I see here are how to specify the internal
>>window (saying the smallest internal window containing windows 10, 14
>>and 17 seems tedious) and how to preserve identities of windows within
>>such configurations (`set-window-configuration' is notorious for
>>breaking the 'window overlay-property).
>
>
> Ooops, sorry, but i haven't understand this paragraph..what do you
> want to say (maybe my english is to bad)?!

Merely what you asked about `save-window-configuration' above - how to
turn a collection of windows into a frame and vice versa.  But how do we
identify collections of windows: By giving every window a group number
you might say, specifying a collection as the set of all windows with
that number.  However, I probably simply want to clone a collection of
windows into a second frame.  What number do I assign the new windows?
I save a collection into a configuration and restore that configuration
later.  Are numbers retained?  Maybe all these issues are trivial, but
better think about them now.

>>... and `other-window' always stays within one and the same group, I
>>presume.  We then probably want a command `other-group' and bind it to
>>C-x ... o.
>
> other-window is adviced:
[...]
> This function has to handle all properly situations for itself.
> `ecb-get-other-window-smart' is an example for such a function."

I see.  Nevertheless, if we talk about groups (or "perspectives") from
an Emacs point of view, we'll have to provide primitives for switching
between groups, independently from how ECB handles this.  Later you can
decide whether and how you want to use these primitives from ECB.