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

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

[joakim]

<klaus.berndl@sdm.de> writes:

> Hi,
>
> first of all thanks!
>
> But some remarks:
>
> I'm sure Emacs should offer out-of-the-box internal concepts to allow IDEs like ECB setting up a window-management-engine as needed by a modern IDE - this includes stuff like preventing a window from being deleted by delete-other-windows and something more which has been already discussed...
>
> But: I'm not sure if doing this a c-level is the right way. Why? IMHO ECB should be runable with Emacs as well with XEmacs. And if all these window-enhancements would be done at c-level at Emacs then the incompatibilities between Emacs and XEmacs would become more and more...
>
> Of course Emacs and XEmacs are already quite incompatible but IMHO such important basic stuff like preventing windows from some operations should be a concept both flavors should support identically - at least concerning the programming interface a tool like ECB would see and use...
>
> Your opinion?

This was discussed on emacs-devel, and the emacs maintainers prefered
the C level implementation for various reasons.

IMHO this C level patch is fairly simple so it should be possible to
apply it to xemacs also, although I dont know much about xemacs.
Maybe someone more familiar with xemacs would care to comment. 

I think its difficult to implement this particular interface on the lisp
level, but I might be mistaken. The interface being that you bind a
plist to the windows object, with properties that modifies the behaviour
of windows operations.

Currently the interface appears to become very simple, and I would like
to solicit opinions about it:

- A window property that allows you to "pin" the window, or rather
  inhibit delete-other-windows for it. This is currently implemented.

- A window property that allows you to group windows together, such
  that other-window only cycles between windows in the group.

From my understanding of the ECB, these two properties would help to
implement much of the current functionality ECB now uses advice for.   

>
> Ciao,
> Klaus
>
> joakim@verona.se wrote:

-- 
Joakim Verona

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

[klaus.berndl]

joakim@verona.se wrote:
> <klaus.berndl@sdm.de> writes:
> 
>> Hi,
>> 
>> first of all thanks!
>> 
>> But some remarks:
>> 
>> I'm sure Emacs should offer out-of-the-box internal concepts to
>> allow IDEs like ECB setting up a window-management-engine as needed
>> by a modern IDE - this includes stuff like preventing a window from
>> being deleted by delete-other-windows and something more which has
>> been already discussed...    
>> 
>> But: I'm not sure if doing this a c-level is the right way. Why?
>> IMHO ECB should be runable with Emacs as well with XEmacs. And if
>> all these window-enhancements would be done at c-level at Emacs then
>> the incompatibilities between Emacs and XEmacs would become more and
>> more...    
>> 
>> Of course Emacs and XEmacs are already quite incompatible but IMHO
>> such important basic stuff like preventing windows from some
>> operations should be a concept both flavors should support
>> identically - at least concerning the programming interface a tool
>> like ECB would see and use...    
>> 
>> Your opinion?
> 
> This was discussed on emacs-devel, and the emacs maintainers prefered
> the C level implementation for various reasons.
> 
> IMHO this C level patch is fairly simple so it should be possible to
> apply it to xemacs also, although I dont know much about xemacs.
> Maybe someone more familiar with xemacs would care to comment.
> 
> I think its difficult to implement this particular interface on the
> lisp level, but I might be mistaken. The interface being that you
> bind a plist to the windows object, with properties that modifies the
> behaviour of windows operations.
> 
> Currently the interface appears to become very simple, and I would
> like to solicit opinions about it:
> 
> - A window property that allows you to "pin" the window, or rather
>   inhibit delete-other-windows for it. This is currently implemented.
> 
> - A window property that allows you to group windows together, such
>   that other-window only cycles between windows in the group.
> 
> From my understanding of the ECB, these two properties would help to
> implement much of the current functionality ECB now uses advice for.

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

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:

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?

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

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

Ciao,
Klaus

>> 
>> Ciao,
>> Klaus
>> 
>> joakim@verona.se wrote:

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

[martin rudalics]

 > 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".

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

[klaus.berndl]

martin rudalics wrote:
>  > 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? 

To all questions: YES, except the recursively subdividing one: What do
you mean exactly?

Currently the concept of ECB is:
- Exactly one frame
- The is *always* exact ONE edit-area, which is always a rectangle
- The special windows are located either at the left, at the right or
on top of the edit area
- the edit-arey can be subdivided in as many windows as possible

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

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
canonical means: always the same sequence beginning from top/left-most,
ie. the same order an unadviced version of `next-window' would walk
through

>What mechanism do you use to access a window outside the
> edit-area - do you suspend advices?

What do you mean with "access"?

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

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

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

> 
>  > 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'?

Yes, probably this would be possible!

> 
>  > 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".

yes, this was my intention - see above...

Klaus

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

[klaus.berndl]

klaus.berndl@sdm.de wrote:
> martin rudalics wrote:
>>  > 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?
> 
> To all questions: YES, except the recursively subdividing one: What do
> you mean exactly?
> 
> Currently the concept of ECB is:
> - Exactly one frame

sorry, misunderstandable: Must be: Exactly one frame *for ECB*
(of course there can be opened other coexistent frames used for
'not-ECB-editing' - all ECB-operations always affect the ECB-frame,
no other frame, all adviced are 100% save concerning this)

> - The is *always* exact ONE edit-area, which is always a rectangle
> - The special windows are located either at the left, at the right or
> on top of the edit area
> - the edit-arey can be subdivided in as many windows as possible
> 
>> 
>>  > 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?
> 
> 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
> canonical means: always the same sequence beginning from
> top/left-most, ie. the same order an unadviced version of
> `next-window' would walk through
> 
>> What mechanism do you use to access a window outside the
>> edit-area - do you suspend advices?
> 
> What do you mean with "access"?
> 
>> 
>>  > 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.
> 
> 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... 
> 
>> 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...
> 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...
> 
>> 
>>  > 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'?
> 
> Yes, probably this would be possible!
> 
>> 
>>  > 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".
> 
> yes, this was my intention - see above...
> 
> Klaus

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

[martin rudalics]

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

 > Currently the concept of ECB is:
 > - Exactly one frame

Does that mean I can't run ECB in two frames simultaneously?

 > - The is *always* exact ONE edit-area, which is always a rectangle

I suppose this will be the basic invariant.

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

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

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

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

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

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

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

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.

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

[martin rudalics]

 > The compile-window is used to display all stuff like help-buffers, compile-
 > grep-buffer etc...

Do you mean that C-h ... are not allowed to display the help buffer in
the edit-area?  How do you achieve that?

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

Did you ever try to tackle these problems with `same-window-regexps' or
`same-window-buffer-names'?  Though I suppose they are too fuzzy for
your purposes.

 > Redraw the ECB screen according to the layout set in `ecb-layout-name'.

How do you get the structure needed for splitting windows into a layout
- do you use the `window-tree' function?

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

Is `ecb-window-configuration-data' based on
`current-window-configuration'?  In this case you always get edit-area,
special windows, and whatever have you in one big pot.  Do you trim away
windows you don't need then?

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

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).

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

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

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

[klaus.berndl]

martin rudalics wrote:
>  > The compile-window is used to display all stuff like help-buffers,
>  compile- > grep-buffer etc...
> 
> Do you mean that C-h ... are not allowed to display the help buffer in
> the edit-area?  How do you achieve that?

By setting `temp-buffer-show-function' to the following ecb-function
which does this.
You see that it uses at the end the adviced `display-buffer' of ECB which
does the final trick, i.e. using the compile-window for all buffers
an ECB user has to customized being displayed in the compile window
(default is all help-buffers, the compile, grep and some others...)

-------
(defun ecb-temp-buffer-show-function-emacs (buf)
  ;; cause of running the hooks in `temp-buffer-show-hook' we must use
  ;; save-selected-window (s.b.). But maybe `display-buffer' calls
  ;; `ecb-toggle-compile-window' which completely destroy all windows and
  ;; redraw the layout. This conflicts with the save-selected-window.
  ;; Therefore we toggle the compile-window before the save-selected-window!
  (when (ecb-compilation-buffer-p buf)
    (ecb-layout-debug-error "ecb-temp-buffer-show-function-emacs: comp-buffer: %s"
                            buf)
    (when (and (equal (selected-frame) ecb-frame)
               (equal 'hidden (ecb-compile-window-state))
               ;; calling this from minibuffer (e.g. completions)
               ;; seems to cause problems
               (not (equal (minibuffer-window ecb-frame) (selected-window))))
      (ecb-layout-debug-error "ecb-temp-buffer-show-function-emacs: comp-win will toggled")
      (ecb-toggle-compile-window 1)))
  (save-selected-window
    (save-excursion
      ;; this call to `display-buffer' runs the adviced version of ECB which
      ;; always handles all the compile-window stuff if buf is a
      ;; compile-buffer in the sense of `ecb-compilation-buffer-p'.
      (let ((win (display-buffer buf)))
        (ecb-layout-debug-error "ecb-temp-buffer-show-function-emacs: win: %s, buf: %s"
                                win buf)
        (select-window win)
        (setq minibuffer-scroll-window win)
        (set-buffer buf)
        (run-hooks 'temp-buffer-show-hook)))))
-------

maybe you now get an impression how it works: ECB has its own display-buffer
version and this one is used in all places where necessary to display
the right buffer in the right window...

some years ago one of my problem was, that not all builtin functions
of Emacs which do displaying buffers seem to have used `display-buffer'
internaly - so probably ECB had the need to advice more functions as
necessary...

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?


> 
>  > 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...
> 
> Did you ever try to tackle these problems with `same-window-regexps'
> or `same-window-buffer-names'?  Though I suppose they are too fuzzy
> for 
> your purposes.

Indeed - i tried it a long long time ago but i gave up (i must admit
to understand this stuff in deep is not easy)

> 
>  > Redraw the ECB screen according to the layout set in
> `ecb-layout-name'. 
> 
> How do you get the structure needed for splitting windows into a
> layout - do you use the `window-tree' function?

No because the window-tree function is too young - ECB exists already
when Emacs 20 was used...

The basic mechanism is at follows:

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

the there is a macro `ecb-layout-define' which allows easily
programming new layouts, here is an example for using this macro:

-------
(ecb-layout-define "left4" left
  "This function creates the following layout:

   -------------------------------------------------------
   |              |                                      |
   |              |                                      |
   |              |                                      |
   |  Directories |                                      |
   |              |                                      |
   |              |                                      |
   |              |                                      |
   |--------------|                 Edit                 |
   |      |       |                                      |
   |      |       |                                      |
   |      |       |                                      |
   | Sour | Hist  |                                      |
   |      |       |                                      |
   |      |       |                                      |
   |      |       |                                      |
   -------------------------------------------------------
   |                                                     |
   |                    Compilation                      |
   |                                                     |
   -------------------------------------------------------

If you have not set a compilation-window in `ecb-compile-window-height' then
the layout contains no persistent compilation window and the other windows get a
little more place."
  (ecb-set-directories-buffer)
  (ecb-split-ver 0.5)
  (ecb-set-sources-buffer)
  (ecb-split-hor 0.5)
  (ecb-set-history-buffer)
  (select-window (next-window)))
-------

This results in a function ecb-layout-function-left4 which
is called from the `ecb-redraw-layout-full'-"framework".

ECB offers also an intercative layout-creation-engine where
a user can define own layouts with a specialized layout-creation-
frame - when the user is fine with its new layout he pressed
"save" and a new call to ecb-layout-define with all the necessary
splits etc. is stored in a file "user-layouts" which is loaded 
at starttime of ECB...

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.

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?!

> 
>  > 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. 
> 
> Is `ecb-window-configuration-data' based on
> `current-window-configuration'?  In this case you always get
> edit-area, 
> special windows, and whatever have you in one big pot.  Do you trim
> away 
> windows you don't need then?

No, it return other informations but these informations are stored
extra in an after-advice of current-window-configuration in a
window-config-cache of ECB - and another aftre advice of
set-window-configuration uses this stored extra information...
To complex to describe all details here ;-)

Here is the docstring of ecb-window-configuration-data:

-------
Return current window configuration of the ecb-frame as a list with the
following structure:
1. The number of the edit-window if point is one of the edit-windows, nil
   otherwise
2. current point if one of the edit-windows is selected, nil otherwise.
3. Data of all edit-windows in form of a list: Everey listelement is a list
   again with first subelement is the buffer of an edit-window, second
   subelement is the `window-start' of this window, third is the
   `window-point' and fourth subelement is the result of `ecb-get-window-size'
   for this window. This data-list has the same ordering as
   `ecb-canonical-edit-windows-list'.
4. Data of the compile window or nil (if there is no compile-window visible):
   List with first elem is the buffer of the compile-window, second elem is
   current point of the compile-buffer if the compile-window is selected
   (otherwise nil) and third elem is the current height of the
   compile-window.
5. The window sizes of the ecb-windows as returned by
   `ecb-get-ecb-window-sizes'
-------

> 
>  > 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. 
> 
> 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)?!

> 
>  >>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...
> 
> ... 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:

-------
(defecb-advice other-window around ecb-basic-adviced-functions
  "The ECB-version of `other-window'. Works exactly like the original function
with the following ECB-adjustment: The behavior depends on
`ecb-other-window-behavior'."
  (if (or (not ecb-minor-mode)
          (not (equal (selected-frame) ecb-frame)))
      (ecb-with-original-basic-functions
       ad-do-it)
    (let* ((count (if (ad-get-arg 0)
                      (ad-get-arg 0)
                    1))
           (o-w (ecb-get-other-window count)))
      (select-window o-w))))
-------

You see `ecb-get-other-window' computes the right other
window depending the context the user is. The behavior
of other-window is highly customizable by an option
`ecb-other-window-behavior' - here is the docstring:

-------
"*The behavior of ECB concerning getting an \"other window\".

The following settings are possible:

'all:

ECB will cycle through all windows of the ECB-frame or scroll simply
the next window in the ECB-frame, means it behaves like the original
`other-window' rsp. the original `other-window-for-scrolling'.

'only-edit:

ECB will only cycle through the edit-windows of ECB or only
scroll another edit-window. If the selected window is not an edit-window
then it behaves like with value 'all.

'edit-and-compile:

Like 'only-edit plus the compile window if any. If the
selected window is neither an edit-window nor the compile-window then it
behaves like with value 'all.

'smart:

With this setting ECB tries to choose the `other-window'-destination or the
\"other window\" to scroll in a smart and intuitive way: If point is in one of
the edit-windows and if the edit-area is splitted then always the \"next\"
edit-window is choosen \(whereas the next edit-window of the last edit-window
is the first edit-window)- if the edit-area is unsplitted then the
compile-window is used if there is one. In the context of an
`other-window'-call the ARG of `other-window' will be taken into account.

If one of the special ecb-windows is selected then always the \"next\"
ecb-window is choosen \(whereas the next ecb-window of the last ecb-window is
the first ecb-window). In the context of an `other-window'-call the ARG of
`other-window' will be taken into account. If there is only one ecb-window
then ECB considers also the edit-windows!

If the compile-window is selected then always the last selected edit-window
will be used unless `other-window' has been called with a prefix-argument
unequal 1.

If there is an active minibuffer:

Regardless of the allowed values above ECB handles the situation of an active
minibuffer during a call to `other-window' or `scroll-other-window' like
follows:

If the minibuffer-window is selected then ECB always chooses the window
`minibuffer-scroll-window' points to \(when this variable is set, otherwise
the compile-window or the last selected edit-window is choosen) when the
called command is called to choose the 1. next window \(always true for
scrolling another window or true when `other-window' called without prefix-arg
or with prefix-arg equal 1). Otherwise the window ARG steps away is choosen
\(in case of `other-window).

If there is an active minibuffer but the minibuffer-window is not selected
then `other-window' and `scroll-other-window' behave like the original
version.

In addition to the allowed values above the value of this option can also be a
function:

This function gets seven arguments:
1. A canonical list of all currently visible windows of the `ecb-frame'
2. A canonical list of all currently visible edit-windows
3. A canonical list of all currently visible ecb-windows
4. The window-object of the compile-window if there is any.
5. The minibuffer-window of the ECB-frame if there is an active minibuffer.
5. The result of the function `ecb-where-is-point' - see the documentation
   of this function for details.
6. An integer which indicates how many steps away from the current selected
   window the \"other-window\ is. Is nil when this function is called in
   another context then for `other-window'.
The function has to return a window-object which is then used as \"other
window\" for the command `other-window' or for scrolling another window
\(e.g. with `scroll-other-window').

This function has to handle all properly situations for itself.
`ecb-get-other-window-smart' is an example for such a function."
-------

Klaus

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.

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

[Richard M Stallman]

I suggest that the best way to design these features is
to think about the actual uses (such as an IDE) and design
features adequate for those uses.  In other words, avoid
ading more generality than we need.

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

[Eric M. Ludlam]

>>> Richard M Stallman <rms@gnu.org> seems to think that:
>I suggest that the best way to design these features is
>to think about the actual uses (such as an IDE) and design
>features adequate for those uses.  In other words, avoid
>ading more generality than we need.


I agree.  Fiddling Emacs to match a model ECB currently uses will just
make ECB work.  What if there is an ECB and a second program like
Speedbar, that both want to do the same thing.  How do they work
together?

I know speedbar works inside ECB because ECB has special code for it,
but what if it did not?

I'd like to know how ECB, and Speedbar can work at the same time,
without being aware of eachother.  Would the solution really be that
Speedbar needs some ECB client code?

The various MDIs (multi-document interface) programs like Eclipse that
I'm familiar with treat the document area, and the data display
windows as completely different entities.  Eclipse has all these
independent plugins that provide little speedbar like displays that
all get stacked and manipulated by the user in a pretty simple way
that is independent of the document area.

This isn't a dis against ECB, I think it's a great tool, but
architecturally it's a one-way street that starts and ends with ECB.
That could be a positive step in itself, where ECB is the API used for
attaching many different tools around the sides of a set of edit
windows.  If this is a case, we should be explicit about it.

Eric

-- 
          Eric Ludlam:                       eric@siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net

RE: Re[2]: patch for optional inhibit of delete-other-windows(IDE feature)

[klaus.berndl]

Eric M. Ludlam wrote:
>>>> Richard M Stallman <rms@gnu.org> seems to think that:
>> I suggest that the best way to design these features is
>> to think about the actual uses (such as an IDE) and design
>> features adequate for those uses.  In other words, avoid
>> ading more generality than we need.
> 
> 
> I agree.  Fiddling Emacs to match a model ECB currently uses will just
> make ECB work.  What if there is an ECB and a second program like
> Speedbar, that both want to do the same thing.  How do they work
> together?
> 
> I know speedbar works inside ECB because ECB has special code for it,
> but what if it did not?
> 
> I'd like to know how ECB, and Speedbar can work at the same time,
> without being aware of eachother.  Would the solution really be that
> Speedbar needs some ECB client code?
> 
> The various MDIs (multi-document interface) programs like Eclipse that
> I'm familiar with treat the document area, and the data display
> windows as completely different entities.  Eclipse has all these
> independent plugins that provide little speedbar like displays that
> all get stacked and manipulated by the user in a pretty simple way
> that is independent of the document area.
> 
> This isn't a dis against ECB, I think it's a great tool, but
> architecturally it's a one-way street that starts and ends with ECB.
> That could be a positive step in itself, where ECB is the API used for
> attaching many different tools around the sides of a set of edit
> windows.  If this is a case, we should be explicit about it.

I completely agree. Emacs should not be enhanced to support especially
ECB but it should be enhanced in that way so a tool *like* ECB (not
exactly ECB) could be implemented without that heavy advice-stuff
currently needed by ECB.

and IMHO the discussion between Martin and me goes in this direction 
(at least this is my intention ;-): I do not want all special stuff
of ECB into the c-core of Emacs but Emacs should offer a well defined
interface to allow tools like ECB introducing a smart window-layout-
engine as needed by IDE-functionality

For this some window-pining and -grouping is needed as suggested by
Joakim (this is nothing special for ECB but can be very useful for
other tools too - maybe speedbar)

Then a mechanism is needed to display certain buffers in certain windows.
For this porting display-buffer to elisp is a great step forward.

Also very helpful could be to save not only the window-configuration of the
whole frame but also to save and restore the current subwindow-configuration
of a certain window - i do not know if window-tree already supports that
somehow?!

Eric, do we agree with that?

Klaus

> 
> Eric

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

[Eric M. Ludlam]

>>> <klaus.berndl@sdm.de> seems to think that:
>Eric M. Ludlam wrote:
>>>>> Richard M Stallman <rms@gnu.org> seems to think that:
>>> I suggest that the best way to design these features is
>>> to think about the actual uses (such as an IDE) and design
>>> features adequate for those uses.  In other words, avoid
>>> ading more generality than we need.
>> 
>> 
>> I agree.  Fiddling Emacs to match a model ECB currently uses will just
>> make ECB work.  What if there is an ECB and a second program like
>> Speedbar, that both want to do the same thing.  How do they work
>> together?
>> 
>> I know speedbar works inside ECB because ECB has special code for it,
>> but what if it did not?
>> 
>> I'd like to know how ECB, and Speedbar can work at the same time,
>> without being aware of eachother.  Would the solution really be that
>> Speedbar needs some ECB client code?
>> 
>> The various MDIs (multi-document interface) programs like Eclipse that
>> I'm familiar with treat the document area, and the data display
>> windows as completely different entities.  Eclipse has all these
>> independent plugins that provide little speedbar like displays that
>> all get stacked and manipulated by the user in a pretty simple way
>> that is independent of the document area.
>> 
>> This isn't a dis against ECB, I think it's a great tool, but
>> architecturally it's a one-way street that starts and ends with ECB.
>> That could be a positive step in itself, where ECB is the API used for
>> attaching many different tools around the sides of a set of edit
>> windows.  If this is a case, we should be explicit about it.
>
>I completely agree. Emacs should not be enhanced to support especially
>ECB but it should be enhanced in that way so a tool *like* ECB (not
>exactly ECB) could be implemented without that heavy advice-stuff
>currently needed by ECB.
>
>and IMHO the discussion between Martin and me goes in this direction 
>(at least this is my intention ;-): I do not want all special stuff
>of ECB into the c-core of Emacs but Emacs should offer a well defined
>interface to allow tools like ECB introducing a smart window-layout-
>engine as needed by IDE-functionality
>
>For this some window-pining and -grouping is needed as suggested by
>Joakim (this is nothing special for ECB but can be very useful for
>other tools too - maybe speedbar)
>
>Then a mechanism is needed to display certain buffers in certain windows.
>For this porting display-buffer to elisp is a great step forward.
>
>Also very helpful could be to save not only the window-configuration of the
>whole frame but also to save and restore the current subwindow-configuration
>of a certain window - i do not know if window-tree already supports that
>somehow?!
>
>Eric, do we agree with that?

My concern is not that good window parameters which are ECB
independent and make ECB implementable without advice can't be
devised.  A do agree your current tactics have read to me as
independent of ECB.

My concern is that the implementation won't scale.  A user keystroke
command combination may keep ECB windows independent of manipulation,
but once this API is available new programs will not be affected this
way.  There will still be window walking APIs that someone may write
that doesn't account for ECB or Speedbar, or some other tool using
these features.

A good example is the mode line and header line.  The mode line came
with a defined pattern.  Major modes manipulate the big part, and
there are key insertion points for minor modes, etc.  Everyone gets
along ok there.

The header line appeared, but has no accounting for it's use.  You now
have to choose between Tabbar tabs, or Semantic's sticky-function
mode.  They just don't work together.

I expect what is needed to keep ECB independent of other similar
layout apps is to either pre-define a use pattern the way mode-line
does, or make sure the API enforces independence between multiple
users of the API.

Since the focus is about IDE like behavior, I think a better approach
would be that ECB would cease being "a big browser", and change
instead into a collection of useful plugins/tools/apps/thingies.  In
this way, ECB's file browser, tag browser, history browser are all
just little apps, and there is a core Emacs facility for doing a
layout of these little browser window things.  Speedbar would then
just become one of these independent browser things.

By way of example, you can do this now with frames.  If all of ECB's
window types were put in little frames of the desired size, they are
independent of each other, the edit area, and of speedbar.  What it's
missing is the nice logical layout.

It very well could be that the ECB layout engine would become the
Emacs facility for doing this layout.  What's important is to also
make sure independent tools, using the same API, won't stomp on
each other.

Is this more clear?
Eric

-- 
          Eric Ludlam:                       eric@siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

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

[Stefan Monnier]

> Also very helpful could be to save not only the window-configuration of the
> whole frame but also to save and restore the current subwindow-configuration
> of a certain window

Yes, we want this feature but I don't think we have it yet.  IIUC it
shouldn't be too difficult to add it to the Elisp implementation of
window configurations (which also provide the ability to save a config
on a frame and restore it on another frame, or in another Emacs session
altogether),

That reminds me: is there any progress on this front?


        Stefan

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

[martin rudalics]

 >>Also very helpful could be to save not only the window-configuration of the
 >>whole frame but also to save and restore the current subwindow-configuration
 >>of a certain window
 >
 > Yes, we want this feature but I don't think we have it yet.  IIUC it
 > shouldn't be too difficult to add it to the Elisp implementation of

Elisp, really?  That is, using `split-window'z?  IIUC that's precisely
what Klaus has implemented for ECB.

 > window configurations (which also provide the ability to save a config
 > on a frame and restore it on another frame, or in another Emacs session
 > altogether),
 >
 > That reminds me: is there any progress on this front?

There was never any consensus on any format.

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

[martin rudalics]

 > The various MDIs (multi-document interface) programs like Eclipse that
 > I'm familiar with treat the document area, and the data display
 > windows as completely different entities.  Eclipse has all these
 > independent plugins that provide little speedbar like displays that
 > all get stacked and manipulated by the user in a pretty simple way
 > that is independent of the document area.

Earlier I wrote my own sidebar because I was not able to use two
speedbars simultaneously - say one for file browsing and the other for
displaying tags.  Has this become possible in the meantime?

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

[Eric M. Ludlam]

>>> martin rudalics <rudalics@gmx.at> seems to think that:
> > The various MDIs (multi-document interface) programs like Eclipse that
> > I'm familiar with treat the document area, and the data display
> > windows as completely different entities.  Eclipse has all these
> > independent plugins that provide little speedbar like displays that
> > all get stacked and manipulated by the user in a pretty simple way
> > that is independent of the document area.
>
>Earlier I wrote my own sidebar because I was not able to use two
>speedbars simultaneously - say one for file browsing and the other for
>displaying tags.  Has this become possible in the meantime?

Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
gets separated and you can then make a new one.

Sadly, as I just tried this, the new speedbar frame seems to have the
same buffer as the original.  I wonder when that happened.

Eric

-- 
          Eric Ludlam:                       eric@siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

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

[martin rudalics]

 > Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
 > gets separated and you can then make a new one.

Do you mean the speedbar shipped with Emacs?  It does not have a menu
and it always appears in a separate frame.

Or do you mean the one bundled with ECB?

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

[Eric M. Ludlam]

>>> martin rudalics <rudalics@gmx.at> seems to think that:
> > Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
> > gets separated and you can then make a new one.
>
>Do you mean the speedbar shipped with Emacs?  It does not have a menu
>and it always appears in a separate frame.
>
>Or do you mean the one bundled with ECB?

Sorry, if you right click, you get a context menu.  That's the
speedbar menu, with many and various options.

Clicking in the mode-line will also do it.

Eric

-- 
          Eric Ludlam:                       eric@siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net

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

[martin rudalics]

 >>>Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
 >>>gets separated and you can then make a new one.
[....]
 > Sorry, if you right click, you get a context menu.  That's the
 > speedbar menu, with many and various options.
 >
 > Clicking in the mode-line will also do it.

There's no "detach" in that menu with speedbar version 1.0 and the
doc-string of `speedbar-frame-mode' says

"Currently, only one speedbar is supported at a time."

Are we missing some interesting developments here?

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

[Eric M. Ludlam]

>>> martin rudalics <rudalics@gmx.at> seems to think that:
> >>>Yes.  Go into the speedbar menu, and choose "detach".  That speedbar
> >>>gets separated and you can then make a new one.
>[....]
> > Sorry, if you right click, you get a context menu.  That's the
> > speedbar menu, with many and various options.
> >
> > Clicking in the mode-line will also do it.
>
>There's no "detach" in that menu with speedbar version 1.0 and the
>doc-string of `speedbar-frame-mode' says
>
>"Currently, only one speedbar is supported at a time."
>
>Are we missing some interesting developments here?

Huh, you are right.  That's been in my version since 2000:

|---
| revision 1.170
| date: 2000/06/11 18:44:00;  author: zappo;  state: Exp;  lines: +26 -2
| Added `speedbar-detatch' so we can have multiple speedbars.
| Fixed `speedbar-trim-words-tag-hierarchy' to work w/ semantic.
|---

and when I look in the Emacs/CVS version, it is not there, but
comments about it are.

In ChangeLog.12 I found this:

|---
|2006-05-30  Nick Roberts  <nickrob@snap.net.nz>
|	    * speedbar.el (speedbar-detach): Delete.
|	    (speedbar-easymenu-definition-trailer): Remove speedbar-detach as
|	    it breaks things.
|	    (speedbar-reconfigure-keymaps): Always add extra items to
|	    pop up menu.
|---


I do know that merging between my version and the Emacs version of
Speedbar is difficult since I can't adopt some of the Emacs.<latest version>
specific changes into my repository.  Perhaps it is time I stopped
supporting Emacs 19, eh?

Anyway, it looks like some merging and bug fixing is required as the
last time I merged from Emacs into my repository, I apparently broke
the detach feature.

Eric

-- 
          Eric Ludlam:                       eric@siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

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

[Robert J. Chassell]

    > > Yes.  Go into the speedbar menu, and choose "detach". ...

    Sorry, if you right click, you get a context menu.  That's the
    speedbar menu ...

In today's GNU Emacs CVS snapshot, Wed, 2008 Apr 30 09:45 UTC
GNU Emacs 23.0.60.29 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
started with

     emacs -Q -D
   
     speedbar-version "1.0"

there is no `detach' on the speedbar menu.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

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

[martin rudalics]

 > I suggest that the best way to design these features is
 > to think about the actual uses (such as an IDE) and design
 > features adequate for those uses.  In other words, avoid
 > ading more generality than we need.

At the very moment we have to wait for IDE designers and users to tell
us their needs and experiences.  Next we can evaluate (i) what would be
the core requirements for such systems, and (ii) whether there are any
fringe benefits - for example, the idea to pop up a help or compile
window always at the same position, say at the bottom of a frame,
appears intriguing (to me).

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

[Stefan Monnier]

> fringe benefits - for example, the idea to pop up a help or compile
> window always at the same position, say at the bottom of a frame,
> appears intriguing (to me).

I've been using that for years, in the form of dedicated frames,


        Stefan

Re: [ECB-list] patch for optional inhibit of

[Henry S. Thompson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Klaus writes:

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

I think this is exactly the right way to state the requirement.

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

I think that would be very valuable.  I would be happy to review it.

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFIFv+qkjnJixAXWBoRAsqdAJ479EWCRBJEljDAFso2L9wKSQXKUQCfXGQE
QMTjNrAb11egyLPc38MzIgM=
=Laxp
-----END PGP SIGNATURE-----

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

[Richard M Stallman]

    > But: I'm not sure if doing this a c-level is the right way. Why?
    > IMHO ECB should be runable with Emacs as well with XEmacs. And
    > if all these window-enhancements would be done at c-level at
    > Emacs then the incompatibilities between Emacs and XEmacs would
    > become more and more...

A good-looking IDE requires new features at the C level, so that is
what we should do.

I don't know how these will affect ECB.  Perhaps they will not require
changing its code much, or perhaps they will.  But we will not hold
back from improving Emacs just to keep ECB compatible with XEmacs.

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

[joakim]

As discussed in the IDE threads, it would be desirable to be able to
optionally change certain window operations.

This patch makes it possible to disable delete-other-windows for a
window.

Its only lightly tested, and I offer it here mostly to discuss the
interface.

To test:

- make several windows

-  (set-window-operation-behaviour-flags (window-at 0 0) '(delete-other-windows t))

The topmost window now wont go away even if you do c-x 1 in the other windows.

If the windows plist window-operation-behaviour-flags
delete-other-windows is t, the window is not electable for deletion when
delete-other-windows is run.

I chose this interface mostly for ease of implementation, but I think
its ok in other regards as well.

Next task is to do the same for other-window.

=== modified file 'src/window.c'
--- src/window.c	2008-04-03 02:15:43 +0000
+++ src/window.c	2008-04-25 22:10:09 +0000
@@ -55,6 +55,7 @@
 
 Lisp_Object Qwindowp, Qwindow_live_p, Qwindow_configuration_p;
 Lisp_Object Qscroll_up, Qscroll_down;
+Lisp_Object Qdelete_other_windows;
 Lisp_Object Qwindow_size_fixed;
 extern Lisp_Object Qleft_margin, Qright_margin;
 
@@ -275,6 +276,7 @@
   p->frame = Qnil;
   p->display_table = Qnil;
   p->dedicated = Qnil;
+  p->window_operation_behaviour_flags = Qnil;
   p->pseudo_window_p = 0;
   bzero (&p->cursor, sizeof (p->cursor));
   bzero (&p->last_cursor, sizeof (p->last_cursor));
@@ -1325,6 +1327,32 @@
   return w->dedicated;
 }
 
+DEFUN ("window-operation-behaviour-flags", Fwindow_operation_behaviour_flags, Swindow_operation_behaviour_flags,
+       1, 1, 0,
+       doc: /* Return WINDOW's window_operation_behaviour_flags.
+               returns nil or a plist where keys are
+               window operations, values flags that might modify the operation behaviour'.  */)
+     (window)
+     Lisp_Object window;
+{
+  return decode_window (window)->window_operation_behaviour_flags;
+}
+
+
+DEFUN ("set-window-operation-behaviour-flags", Fset_window_operation_behaviour_flags,
+       Sset_window_operation_behaviour_flags, 2, 2, 0,
+       doc: /* set window operation flags */)
+     (window, arg)
+     Lisp_Object window, arg;
+{
+  register struct window *w = decode_window (window);
+
+  w->window_operation_behaviour_flags = arg;
+
+  return w->window_operation_behaviour_flags;
+}
+
+
 DEFUN ("window-display-table", Fwindow_display_table, Swindow_display_table,
        0, 1, 0,
        doc: /* Return the display-table that WINDOW is using.
@@ -2209,7 +2237,10 @@
 	    break;
 
 	  case DELETE_OTHER_WINDOWS:
-	    if (!EQ (window, obj))
+            //
+	    if ((!EQ (window, obj)) && //obj is not the current window
+                //current window doesnt have delete_other_windows disabled (t inhibits)
+                (NILP(Fplist_get (w->window_operation_behaviour_flags, Qdelete_other_windows))))
 	      Fdelete_window (window);
 	    break;
 
@@ -7398,6 +7429,10 @@
 void
 syms_of_window ()
 {
+
+  Qdelete_other_windows = intern ("delete-other-windows");
+  staticpro (&Qdelete_other_windows);
+
   Qscroll_up = intern ("scroll-up");
   staticpro (&Qscroll_up);
 
@@ -7714,6 +7749,9 @@
   defsubr (&Sset_window_vscroll);
   defsubr (&Scompare_window_configurations);
   defsubr (&Swindow_list);
+  defsubr (&Swindow_operation_behaviour_flags);
+  defsubr (&Sset_window_operation_behaviour_flags);           
+           
 }
 
 void

=== modified file 'src/window.h'
--- src/window.h	2008-01-29 02:05:10 +0000
+++ src/window.h	2008-04-25 15:53:53 +0000
@@ -229,6 +229,9 @@
        enlarged. */
     Lisp_Object orig_total_lines, orig_top_line;
 
+    /* a plist with flags that modifies behaviour of certain window operations*/
+    Lisp_Object window_operation_behaviour_flags;
+    
     /* No Lisp data may follow below this point without changing
        mark_object in alloc.c.  The member current_matrix must be the
        first non-Lisp member.  */


-- 
Joakim Verona

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

[Stefan Monnier]

> As discussed in the IDE threads, it would be desirable to be able to
> optionally change certain window operations.

> This patch makes it possible to disable delete-other-windows for a
> window.

> Its only lightly tested, and I offer it here mostly to discuss the
> interface.

> To test:

> - make several windows

> -  (set-window-operation-behaviour-flags (window-at 0 0) '(delete-other-windows t))

> The topmost window now wont go away even if you do c-x 1 in the other windows.

> If the windows plist window-operation-behaviour-flags
> delete-other-windows is t, the window is not electable for deletion when
> delete-other-windows is run.

I'd rather add window-parameter and set-window-parameter.  After all,
most objects have such things and it's useful for more than just
"behavior flags".

Such an addition is useful in general and can be installed right away.

As for the introduction of special meaning for some parameters so as to
influence delete-other-windows, while I think it may work well, I'd
rather first see it fully developed and shown to be a good fit for ECB,
before installing it.  This is because there's a good chance that it may
not work quite as needed at first and that the design requires some
rounds of refinement until it's really what we want.

So I suggest you work on a separate branch for that.


        Stefan

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

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If the windows plist window-operation-behaviour-flags
>> delete-other-windows is t, the window is not electable for deletion when
>> delete-other-windows is run.
>
> I'd rather add window-parameter and set-window-parameter.  After all,
> most objects have such things and it's useful for more than just
> "behavior flags".
>
> Such an addition is useful in general and can be installed right away.

Ok, I will model it like set-frame-parameter, frame-parameter. Thanks
for the tip!

>
> As for the introduction of special meaning for some parameters so as to
> influence delete-other-windows, while I think it may work well, I'd
> rather first see it fully developed and shown to be a good fit for ECB,
> before installing it.  This is because there's a good chance that it may
> not work quite as needed at first and that the design requires some
> rounds of refinement until it's really what we want.

How do you feel about the current interface:

delete-other-windows t, inhibits delete-other-windows

other-window numeric arg, the arg will group windows together, when
other-window is performed, only windows in the same group are
considered. I plan to do this by adding an argument to next_window.

The parameters might obvioulsy be renamed.



> So I suggest you work on a separate branch for that.

I have set up a local bzr branch to work in, that should be enough right?

>
>
>         Stefan
-- 
Joakim Verona

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

[Stefan Monnier]

>>> If the windows plist window-operation-behaviour-flags
>>> delete-other-windows is t, the window is not electable for deletion when
>>> delete-other-windows is run.
>> 
>> I'd rather add window-parameter and set-window-parameter.  After all,
>> most objects have such things and it's useful for more than just
>> "behavior flags".
>> 
>> Such an addition is useful in general and can be installed right away.

> Ok, I will model it like set-frame-parameter, frame-parameter. Thanks
> for the tip!

>> As for the introduction of special meaning for some parameters so as to
>> influence delete-other-windows, while I think it may work well, I'd
>> rather first see it fully developed and shown to be a good fit for ECB,
>> before installing it.  This is because there's a good chance that it may
>> not work quite as needed at first and that the design requires some
>> rounds of refinement until it's really what we want.

> How do you feel about the current interface:
> delete-other-windows t, inhibits delete-other-windows

Honestly?  I think it's terrible (it's just one-step better than using
advice).  But it's the best we have so far.

What I hope to get from the above is an understand of which functions
need to get changed together, then we can create a couple special
window-parameter (call it "foo" and "bar"-windows) and have those
handled accordingly in delete-other-windows, etc...

The crucial difference is that "foo" and "bar" shouldn't have anything
directly to do with delete-other-windows but should instead express
a particular intention behind the use of the window.  I.e. an attribute
similar to `dedicated'.

>> So I suggest you work on a separate branch for that.
> I have set up a local bzr branch to work in, that should be enough right?

Yes, that's fine.  If you want to make it public, it's even better.
Note also that I don't see any copyright assignment from you, so you may
want to address this if you want to have your code installed (or if you
want to place a mirror of your branch in Emacs's bzr repository).


        Stefan

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

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> How do you feel about the current interface:
>> delete-other-windows t, inhibits delete-other-windows
>
> Honestly?  I think it's terrible (it's just one-step better than using
> advice).  But it's the best we have so far.

This was pretty funny to me :) Obviously you should be honest.

> What I hope to get from the above is an understand of which functions
> need to get changed together, then we can create a couple special
> window-parameter (call it "foo" and "bar"-windows) and have those
> handled accordingly in delete-other-windows, etc...

> The crucial difference is that "foo" and "bar" shouldn't have anything
> directly to do with delete-other-windows but should instead express
> a particular intention behind the use of the window.  I.e. an attribute
> similar to `dedicated'.

Currently I'm working towards this interface:

window-parameter
set-window-parameter

These are like their frame counterparts.

The properties are like:

"pin" - if t, the window isnt deleted by delete-other-windows

"group" - these windows are in a group together and other-window cycles
between windows which has the same "group" value. I plan to implement
this in next_window().

I'm sure theres even better interfaces, so please be honest :)

Maybe "pin" and "group" should really be one parameter or whatever.

>
>>> So I suggest you work on a separate branch for that.
>> I have set up a local bzr branch to work in, that should be enough right?
>
> Yes, that's fine.  If you want to make it public, it's even better.
> Note also that I don't see any copyright assignment from you, so you may
> want to address this if you want to have your code installed (or if you
> want to place a mirror of your branch in Emacs's bzr repository).

Ok, how do I go about getting an assignment?

>
>         Stefan
-- 
Joakim Verona

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

[Miles Bader]

joakim@verona.se writes:
> The properties are like:
>
> "pin" - if t, the window isnt deleted by delete-other-windows
>
> "group" - these windows are in a group together and other-window cycles
> between windows which has the same "group" value. I plan to implement
> this in next_window().
>
> I'm sure theres even better interfaces, so please be honest :)
>
> Maybe "pin" and "group" should really be one parameter or whatever.

Can you give examples of what sort of real-world situation they'd be
used in?

Thanks,

-Miles

-- 
Selfish, adj. Devoid of consideration for the selfishness of others.

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

[Eric M. Ludlam]

>>> Miles Bader <miles.bader@necel.com> seems to think that:
>joakim@verona.se writes:
>> The properties are like:
>>
>> "pin" - if t, the window isnt deleted by delete-other-windows
>>
>> "group" - these windows are in a group together and other-window cycles
>> between windows which has the same "group" value. I plan to implement
>> this in next_window().
>>
>> I'm sure theres even better interfaces, so please be honest :)
>>
>> Maybe "pin" and "group" should really be one parameter or whatever.
>
>Can you give examples of what sort of real-world situation they'd be
>used in?
  [ ... ]

I realize the conversation has moved on past this post, but I wanted
to provide an opinion also.  A very simple use case is Speedbar.  I
commonly get folks asking if speedbar can be stuck onto the side of
the frame they are using for editing.  The buffer suggestion here
might would work for that.

I always thought it would be nice if frame parameters could be used to
stick two frames together.  Unfortunately, this would require some UI
cross platform work between X, tty, w32, and Mac.  The benefit is that
it could be easily explained, and require and no new keybindings.
Window configurations could be used for individual sub-frames.  Better
yet, multiple tools could append frames together independently, and
and have it makes sense via frame concatenation, tabs, or tiling.  If
windows are used, you would not be able to have ECB and Speedbar work
together independently.  As it stands now, ECB is Speedbar aware, and
knows how to deal with it specifically.  I don't think ECB would be up
for knowing about every frame that would ever want to be attached to
an editing frame unless ECB became the official API for these
persistent windows.

Eric

-- 
          Eric Ludlam:                       eric@siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net