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

[martin rudalics <rudalics@gmx.at>]

 > Hmm, its a good starting point but not complete. Simply think of ECB
 > as a tool which wants to display some special windows beside an
 > "edit-area" whereas the former one are used to display informational
 > context stuff as parsed tags of the current buffer in the edit-area
 > or a file- and directory tree or a buffer-history or or or...
 > The latter one (the edit-area) should give the user the feeling as
 > if all windows of this edit-area would be the only windows in the
 > frame so all standard operations would act as if the edit-windows
 > would be the only windows in the frame...

Is the edit-area always a rectangle?  Can it be always created by
recursively subdividing an initial window?  Is there always at most one
edit-area?  Is there at most one edit-area in one and the same frame?

 > Well, a window property for preventing other windows outside the
 > edit-area from being deleted or for a navigation only in the edit-
 > area by other-window would be a good starting point but its not the
 > end of the story:

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?
What mechanism do you use to access a window outside the edit-area - do
you suspend advices?

 > What about saving and later restoring the current window layout of the
 > edit-area (means only these windows inside the edit-area) without
 > affecting the layout of the special windows?

Do you also need to save and restore the layout of the non-edit-area?
Earlier I got the impression that the non-edit-area would be immutable,
so you could easily include it in the saved configuration.  Do you want
the edit-area occasionally occupy the entire frame?

 > And how to implement an option like
 > `ecb-layout-always-operate-in-edit-window'
 > (see docstring) without adviceing e.g. switch-to-buffer?
 >
 > Just take a look at the docstring of the adviced `switch-to-buffer':
 > IMHO even with the new pins advices are needed to offer a smart and
 > convenient usage of an IDE like ECB...

Couldn't this be done with the help of a `switch-buffer-function'?

 > maybe i will find next weekend the needed time to write down a small
 > "functional reqirement specification" which core functionality would
 > be required by Emacs to rewrite ECB without a lot of its advices or
 > at least with much simpler advices...

If possible, please list also invariants which can be used to cut down
the overhead for providing these requirements.  Like "for any frame the
number of edit-areas it displays is zero or one".