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

[klaus.berndl]

martin rudalics wrote:
>  > To all questions: YES, except the recursively subdividing one:
>  What do > you mean exactly?
> 
> My question was badly formulated.  I wanted to know whether the
> edit-area could be always obtained by recursively splitting a window
> in some arbitrary way such that the resulting tiling would encompass
> the _entire_ edit-area.  That is, none of the windows produced by
> these splittings would not be part of the edit-area.
> 
> A simple example not following this concept would be: Split a window
> vertically, split the lower window vertically, the upper two windows
> (and their sub-windows) would constitute the edit-area, the lowest
> window would not be part of the edit-area.
> 
> I'm asking because currently reasoning about tiling Emacs windows is
> purely operational.  A tiling is always the result of recursively
> splitting an initial window into sub-windows.

Ok, now i understand, thanks. well, the answer is YES, means, each window
produced by splitting a window already contained in the edit-area (at
beginning the edit-area consists of exactly one window, obviously ;-)
will be part of the edit-area too.

> 
>  > Currently the concept of ECB is:
>  > - Exactly one frame
> 
> Does that mean I can't run ECB in two frames simultaneously?

Currently not, but it would not be too hard to add multi-frame support
i would suppose...

> 
>  > - The is *always* exact ONE edit-area, which is always a rectangle
> 
> I suppose this will be the basic invariant.

YES, and probably the most important one.

> 
>  > - The special windows are located either at the left, at the right
>  or > on top of the edit area
> 
> Is the compile window you mention below not a special window?

Sorry, for my not very precise wording... Purely all windows outside
the edit-area are somehow 'special' but what i mean is: The browsing-
windows of ECB are special with that respect, that they are all dedicated
to one buffer - you can dot switrch buffer in such a window.
The compile-window is used to display all stuff like help-buffers, compile-
grep-buffer etc... is customizable by mode and regexp which buffers should
be automatically alwasy being displayed in the compile-buffer - example:
When you do switch-to-buffer in one of the edit-windows and you insert a
buffer which is customized to be displayed in the compile-window then
ECB will switch to this buffer in the compile-window (if it is displayed
in the current layout) - in generell the advices of switch-to-buffer and
pop-to-buffer are one of the most important ones currently because
the do all the needed smartness to display the right buffer in the right
window...

> 
>  > - the edit-arey can be subdivided in as many windows as possible
> 
> OK.
> 
>  >>Can all operations you need be subdivided into whether they either
>  >>apply to all windows in the edit-area or to all windows outside the
>  >>edit-area?
>  >
>  > Almost: Currently ECB needs three canonical window-lists:
>  > - full window list of the ECB-frame
>  > - all windows in the edit-area
>  > - all special ECB-windows
>  > - the compile-window (always displayed at bottom) when displayed
> 
> How do you currently display the compile window, make it go away,
> display it again, ... ?

Go away is simple: This can be achieved by simply performing the unadviced
version of `delete-window' in the complile-window.
All other stuff like showing the compile window again or toggling the
browsing-windows (the dedicated ones, s.a.) or temporarly maximizing
one of the browsing windows to the full column is performed by the heart
and soul of the layout-engine of ECB, by `edb-redraw-layout-full':

--- the docstring ---
ecb-redraw-layout-full is a compiled Lisp function in `ecb-layout.el'.
(ecb-redraw-layout-full &optional no-buffer-sync ecb-windows-creator
window-configuration-data no-ecb-windows emergency)

Redraw the ECB screen according to the layout set in `ecb-layout-name'. After
this function the edit-window is selected which was current before redrawing.
If no-buffer-sync is not nil then the ecb-buffers will not be synchronized. If
ecb-windows-creator is not nil then it will be used to draw the layout instead
of the standard layout. If window-configuration-data is not nil it must be an
object returned by `ecb-window-configuration-data' and will be used for
restoring the layout. If emergency is not nil then all other args will be
ignored and the layout will be redrawn like defined in the current layout and
the edit-area will be unsplitted and will just contain the buffer before the
emergency-redraw.
---

Not important, you understand this function but what you see is, there
are some parameter (e.g. NO-ECB-WINDOWS) which determine what should be done.
This is quite long and compley function and what it does is basically: It 
completely
cleans the whole ECB-frame and then redraws exactly that window-layout which
is needed in the current context.

> 
>  > canonical means: always the same sequence beginning from
>  top/left-most, > ie. the same order an unadviced version of
>  `next-window' would walk > through
> 
> I suppose you mention `next-window' here because you use it to modify
> the standard commands - sometimes they should operate on the full
> windows list, sometimes just on the edit-area list?

No, i do not use next-window directly - to get the needed canonical
window-list i always get the full window-list of the ECVB-frame (with
Emacs 21.X i use `window-list' because it returen the right ordered
list i need; with XEmacs i have to use `walk-window' to get the right
canonical window-list).
The list is then filtered to the current needs:
- ecb-window-list: Throwing away all NOT dedicated windows
- edit-area-list: Throwing away all dedicated windows and the compile
  window
And now you are right: Many commands operate operate on one of
these lists, depending on the current usage-context...
And here you see, why the "group"-window-property suggested
by joakim could be very usefull by ECB - all browsing-windows
would be one group, the compile-window would by a group, the edit-
windows would be a group....

> 
>  >>What mechanism do you use to access a window outside the
>  >>edit-area - do you suspend advices?
>  >
>  > What do you mean with "access"?
> 
> I meant "select", for example, using `other-window'.  How do you
> select 
> the compile-window or the other special ECB-windows when you're in the
> edit-area?

Ah, now i understand: I simple use `select-window' with right window-
object...the window-object of the compile-window is always stored
in a variable and the dedicated browsing windows are selectable
by buffer-name...

> 
>  > Yes, currently the layout of the non-edit-area is immutable in this
>  > sense that redrawing the whole layout of the ECB-frame resizes the
>  > special windows back to their cusomized (via customize) sizes
>  > (can be absolute or - prefered - relative) whereas the sizes
>  > of the windows in the edit-area will be preserved by a
>  layout-redraw, > means the sizes the user has choosen by dragging
> modeline or what else... 
> 
> Does that mean special windows are not fixed-size, so the user can
> freely resize them?

Yes, but the user can customize this by an option...if unfixed the
user can resize the special windows by mouse or keyboard but as
already mentioned, a following redraw by `ecb-redraw-layout-full'
will resize these windows to its customized sized (which can be absolute
ones or relative ones) - and as explained above such a full redraw
is quite often necessary....
To preserve the user-resized window-sizes of the special windows
is on my TODO-list ;-)
With edit-windows it already works fine...

> 
>  >>Do you want the edit-area occasionally occupy the entire frame?
>  >
>  > Yes, there is a command which allows to hide or to toggle
>  visibility > of the special windows - you can imagine that this
>  needs complex and > smart code-stuff to preserve the window-layout
>  of the edit-area during > that, but it works stable and error-less...
> 
> We should be able to do this using window-configurations.

Can't judge this

> 
>  > IMHO temporarly hidding the special windows (ie. only the edit-area
>  > and all its windows are visible in the ECB-frame) is a very
>  important > feature of an IDE...
> 
> Sure.