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: patch for optional inhibit of delete-other-windows(IDE feature)

[joakim]

Miles Bader <miles.bader@necel.com> writes:

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

It has been discussed in other threads, but heres a simple example.

I would like a special window that displays information that many
packages choose to display in the mode-line. Lets call this a
status-window.

The special window will for instance display date-time, and what song is
playing in EMMS, and chanel information from ERC.

I dont want this information in every mode-line, just in this special
window.  Also, I dont want this window to be deleted by
delete-other-windows, just as I dont want a windows mode-line to be
deleted implicitly. I also dont want to enter the status-window on
other-window, I just want the window to sit there and display stuff like
a toolbar or whatever. The dedicated flag is not sufficient for this
scenario.

The special window would have "pin" set to t, and "group" set to
something other than nil, perhaps "status". 

The ECB has much more advanced use-cases, but works basically this way.
The ECB has for instance a directory browser and a speed-bar sitting in
special windows like these, although the ECB implements this with
advice. The goal is not needing advice to implement what the ECB wants
so ECB can be merged. 

Hope this helps.

>
> Thanks,
> -Miles
-- 
Joakim Verona

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

[Stefan Monnier]

> Currently I'm working towards this interface:

> window-parameter
> set-window-parameter

> These are like their frame counterparts.

Yes, as mentioned this is fine and we can install this right away.

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

This sounds pretty good, actually.  Provided it's flexible/powerful
enough, obviously.

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

Right.  Maybe all the pinned windows can just be in their own group.
But maybe conflating the two is not good enough.


        Stefan

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

[joakim]

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


>> Maybe "pin" and "group" should really be one parameter or whatever.
>
> Right.  Maybe all the pinned windows can just be in their own group.
> But maybe conflating the two is not good enough.

My intuition is that conflating the properties is not quite good enough,
so I will start with two separate properties. I intuit this because
maybe you want different pinned groups, and maybe you want different
groups that are not pinned.

However, I have as yet no real use-case for the above options, except my
status-window example, and the ECB, neither of which seem to require
both "pin" and "groups".

>
>
>         Stefan
-- 
Joakim Verona

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

[klaus.berndl]

joakim@verona.se wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> 
>>> Maybe "pin" and "group" should really be one parameter or whatever.
>> 
>> Right.  Maybe all the pinned windows can just be in their own group.
>> But maybe conflating the two is not good enough.
> 
> My intuition is that conflating the properties is not quite good
> enough, so I will start with two separate properties. I intuit this
> because maybe you want different pinned groups, and maybe you want
> different groups that are not pinned.
> 
> However, I have as yet no real use-case for the above options, except
> my status-window example, and the ECB, neither of which seem to
> require both "pin" and "groups".

not true: Especially ECB could have great benefit from the "groups"!
ECB not only displays special "browsing" windows but often also a 
compile-window which should also be prevented from being deleted but
should handled slightly different - especially the window-switching
commands could benefit from the groups-feature!

Running next-window or other-window in a typical ECB-layout will take
usage of the "group"-parameter!

Klaus

So my recommendation: Do not conflate

> 
>> 
>> 
>>         Stefan

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

[Jason Rumney]

joakim@verona.se wrote:

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

The first definitely needs renaming. Its value is used to determine the 
behaviour of the current window (not other windows), and its value is 
used in the inverse way that the name suggests. Perhaps inhibit-deletion 
would be better. The downside is that the rename loses the association 
with the function delete-other-windows, but is that the only function 
that needs to look at this property anyway?

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

[klaus.berndl]

Jason Rumney wrote:
> joakim@verona.se wrote:
> 
>> 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.
>> 
> 
> The first definitely needs renaming. Its value is used to determine
> the behaviour of the current window (not other windows), and its
> value is used in the inverse way that the name suggests. Perhaps
> inhibit-deletion would be better. The downside is that the rename
> loses the association with the function delete-other-windows, but is
> that the only function that needs to look at this property anyway?

no, definitly delete-window too - in case of ECB it must be ensured
that a user can not delete one of the special windows...
Currently the advice of delete-window prevents from this....
Then split-window-* because such special windows must also not
splitted...

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

[joakim]

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

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

I've received and returned copyright assignment papers now, so review
and merging of this part of the patch could proceed now.

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

I agree with the refinement process idea, but tackling the entirety of
the ECB is too large a task for me at present.

I had another idea that seemed easier: manipulating the emacs GUD
interface layout, so certain windows become the new types of context
windows. WDYT?


-- 
Joakim Verona

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

[Stefan Monnier]

> I agree with the refinement process idea, but tackling the entirety of
> the ECB is too large a task for me at present.

Clearly, I'd expect Klaus to help you out.  And it doesn't have to be
fully done in its entirety.  Just enough to make you both confident that
it's a good solution.


        Stefan

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

[Richard M Stallman]

It looks good except for the name `window-operation-behaviour-flags'.
It has two problems:

1. British spelling for "behavior".

2. "Flags" suggests a word of bit flags.  Since this is a plist,
I suggest `window-operation-plist' or something like that.

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

[Stefan Monnier]

> 1. British spelling for "behavior".

> 2. "Flags" suggests a word of bit flags.  Since this is a plist,
> I suggest `window-operation-plist' or something like that.

Also, I'd rather have an `alist' (it's what we use in most other
places, and would be needed if we ever want to make window-local
variables).


        Stefan


PS: I'm also partial to alists.

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

[joakim]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

Heres a new version of the patch. New stuff:

- The interface is now an alist tied to the window.
I think Stefan prefered this.

acessors:
set-window-parameter
window-parameter

- set "pin" to t, and the window will not go away on delete-other-winows
- set "group" to something, and all windows with the same value will be
considered in the same window group, which affects other-window for
instance.

- I also have some hackish elisp code to show how the interface works.

This is all only lightly tested, but looks IMHO promising.

Issues:

- I didn't adress Klaus concern with switch-to-buffer yet, I'm not sure how
to proceed there.

- I broke an optimization, marked as FIXME in windows.c. It doesnt look
  especially important so I wont not spend time on it until everything
  works properly.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bzr.diff --]
[-- Type: text/x-patch, Size: 7131 bytes --]

=== modified file 'src/window.c'
--- src/window.c	2008-04-03 02:15:43 +0000
+++ src/window.c	2008-04-29 09:40:34 +0000
@@ -55,6 +55,8 @@
 
 Lisp_Object Qwindowp, Qwindow_live_p, Qwindow_configuration_p;
 Lisp_Object Qscroll_up, Qscroll_down;
+Lisp_Object Qpin;
+Lisp_Object Qgroup;
 Lisp_Object Qwindow_size_fixed;
 extern Lisp_Object Qleft_margin, Qright_margin;
 
@@ -82,7 +84,8 @@
 					 Lisp_Object *));
 static int foreach_window_1 P_ ((struct window *,
 				 int (* fn) (struct window *, void *),
-				 void *));
+				 void *,
+                                 int));
 static Lisp_Object window_list_1 P_ ((Lisp_Object, Lisp_Object, Lisp_Object));
 
 /* This is the window in which the terminal's cursor should
@@ -275,6 +278,7 @@
   p->frame = Qnil;
   p->display_table = Qnil;
   p->dedicated = Qnil;
+  p->window_parameters = Qnil;
   p->pseudo_window_p = 0;
   bzero (&p->cursor, sizeof (p->cursor));
   bzero (&p->last_cursor, sizeof (p->last_cursor));
@@ -1082,7 +1086,7 @@
 
   window = Qnil;
   cw.window = &window, cw.x = &x, cw.y = &y; cw.part = part;
-  foreach_window (f, check_window_containing, &cw);
+  foreach_window (f, check_window_containing, &cw, 1);
 
   /* If not found above, see if it's in the tool bar window, if a tool
      bar exists.  */
@@ -1325,6 +1329,38 @@
   return w->dedicated;
 }
 
+DEFUN ("window-parameters", Fwindow_parameters, Swindow_parameters,
+       1, 1, 0,
+       doc: /* Return WINDOW's window-parameters.
+               returns nil or an alist where values affect window operations.  */)
+     (window)
+     Lisp_Object window;
+{
+  return decode_window (window)->window_parameters;
+}
+
+
+DEFUN ("set-window-parameter", Fset_window_parameter,
+       Sset_window_parameter, 3, 3, 0,
+       doc: /* set window parameters */)
+     (window, prop, val)
+     Lisp_Object window, prop, val;
+{
+  register struct window *w = decode_window (window);
+  register Lisp_Object old_alist_elt;
+  
+  old_alist_elt = Fassq (prop, w->window_parameters);
+  if (EQ (old_alist_elt, Qnil))
+    w->window_parameters = Fcons (Fcons (prop, val), w->window_parameters);
+  else
+    Fsetcdr (old_alist_elt, val);
+
+  //Fplist_put(w->window_parameters,key,value);
+
+  return w->window_parameters;
+}
+
+
 DEFUN ("window-display-table", Fwindow_display_table, Swindow_display_table,
        0, 1, 0,
        doc: /* Return the display-table that WINDOW is using.
@@ -1729,7 +1765,8 @@
 static Lisp_Object
 window_list ()
 {
-  if (!CONSP (Vwindow_list))
+  //if(!CONSP (Vwindow_list))
+  if (1) //never cache the window list for now FIXME
     {
       Lisp_Object tail;
 
@@ -1742,7 +1779,7 @@
 	     new windows at the front of args[1], which means we
 	     have to reverse this list at the end.  */
 	  args[1] = Qnil;
-	  foreach_window (XFRAME (XCAR (tail)), add_window_to_list, &args[1]);
+	  foreach_window (XFRAME (XCAR (tail)), add_window_to_list, &args[1], 0);
 	  args[0] = Vwindow_list;
 	  args[1] = Fnreverse (args[1]);
 	  Vwindow_list = Fnconc (2, args);
@@ -2209,7 +2246,10 @@
 	    break;
 
 	  case DELETE_OTHER_WINDOWS:
-	    if (!EQ (window, obj))
+            //
+	    if ((!EQ (window, obj)) && //obj is not the current window
+                //current window doesnt have "pin" prop set
+                (NILP(Fassq (Qpin, w->window_parameters))))
 	      Fdelete_window (window);
 	    break;
 
@@ -7159,17 +7199,20 @@
 \f
 /* Call FN for all leaf windows on frame F.  FN is called with the
    first argument being a pointer to the leaf window, and with
-   additional argument USER_DATA.  Stops when FN returns 0.  */
+   additional argument USER_DATA.  Stops when FN returns 0.
+   ALLWINDOWS 1 means iterate every window, else only the group of the selected window
+*/
 
 void
-foreach_window (f, fn, user_data)
+foreach_window (f, fn, user_data, allwindows)
      struct frame *f;
      int (* fn) P_ ((struct window *, void *));
      void *user_data;
+     int allwindows;
 {
   /* Fdelete_frame may set FRAME_ROOT_WINDOW (f) to Qnil.  */
   if (WINDOWP (FRAME_ROOT_WINDOW (f)))
-    foreach_window_1 (XWINDOW (FRAME_ROOT_WINDOW (f)), fn, user_data);
+    foreach_window_1 (XWINDOW (FRAME_ROOT_WINDOW (f)), fn, user_data,allwindows);
 }
 
 
@@ -7179,22 +7222,29 @@
    Stop when FN returns 0.  Value is 0 if stopped by FN.  */
 
 static int
-foreach_window_1 (w, fn, user_data)
+foreach_window_1 (w, fn, user_data, allwindows)
      struct window *w;
      int (* fn) P_ ((struct window *, void *));
      void *user_data;
+     int allwindows;
 {
   int cont;
-
+  struct window *current_window=XWINDOW(selected_window);
+  register Lisp_Object group = Fcdr(Fassq(Qgroup, current_window->window_parameters));
+  Lisp_Object group2;
   for (cont = 1; w && cont;)
     {
       if (!NILP (w->hchild))
- 	cont = foreach_window_1 (XWINDOW (w->hchild), fn, user_data);
+ 	cont = foreach_window_1 (XWINDOW (w->hchild), fn, user_data,allwindows);
       else if (!NILP (w->vchild))
- 	cont = foreach_window_1 (XWINDOW (w->vchild), fn, user_data);
-      else
-	cont = fn (w, user_data);
-
+ 	cont = foreach_window_1 (XWINDOW (w->vchild), fn, user_data,allwindows);
+      else{
+        //only call fn if the group of the frames selected window 
+        //is the same as the group of the current window in the loop.
+        group2=Fcdr(Fassq(Qgroup,w->window_parameters));
+        if (allwindows || EQ(group ,  group2  ))
+          cont = fn (w, user_data);
+      }
       w = NILP (w->next) ? 0 : XWINDOW (w->next);
     }
 
@@ -7233,7 +7283,7 @@
      struct frame *f;
      int freeze_p;
 {
-  foreach_window (f, freeze_window_start, (void *) (freeze_p ? f : 0));
+  foreach_window (f, freeze_window_start, (void *) (freeze_p ? f : 0),1);
 }
 
 \f
@@ -7398,6 +7448,13 @@
 void
 syms_of_window ()
 {
+
+  Qpin = intern ("pin");
+  Qgroup = intern ("group");
+  
+  staticpro (&Qpin);
+  staticpro (&Qgroup);
+
   Qscroll_up = intern ("scroll-up");
   staticpro (&Qscroll_up);
 
@@ -7714,6 +7771,9 @@
   defsubr (&Sset_window_vscroll);
   defsubr (&Scompare_window_configurations);
   defsubr (&Swindow_list);
+  defsubr (&Swindow_parameters);
+  defsubr (&Sset_window_parameter);           
+           
 }
 
 void

=== modified file 'src/window.h'
--- src/window.h	2008-01-29 02:05:10 +0000
+++ src/window.h	2008-04-29 10:04:07 +0000
@@ -229,6 +229,11 @@
        enlarged. */
     Lisp_Object orig_total_lines, orig_top_line;
 
+    /* an alist with flags that modifies behaviour of certain window operations.
+       currently "pin" and "group" are special
+     */
+    Lisp_Object window_parameters;
+    
     /* 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.  */
@@ -786,7 +791,8 @@
 extern void freeze_window_starts P_ ((struct frame *, int));
 extern void foreach_window P_ ((struct frame *,
 				int (* fn) (struct window *, void *),
-				void *));
+				void *,
+                                int allwindows));
 extern void grow_mini_window P_ ((struct window *, int));
 extern void shrink_mini_window P_ ((struct window *));
 


[-- Attachment #3: pin-group-demo.el --]
[-- Type: application/emacs-lisp, Size: 1840 bytes --]

[-- Attachment #4: Type: text/plain, Size: 20 bytes --]



-- 
Joakim Verona

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

[klaus.berndl]

joakim@verona.se wrote:
> Heres a new version of the patch. New stuff:
> 
> - The interface is now an alist tied to the window.
> I think Stefan prefered this.
> 
> acessors:
> set-window-parameter
> window-parameter
> 
> - set "pin" to t, and the window will not go away on
> delete-other-winows 
> - set "group" to something, and all windows with the same value will
> be considered in the same window group, which affects other-window for
> instance.
> 
> - I also have some hackish elisp code to show how the interface works.
> 
> This is all only lightly tested, but looks IMHO promising.
> 
> Issues:
> 
> - I didn't adress Klaus concern with switch-to-buffer yet, I'm not
> sure how to proceed there.

maybe by an `switch-to-buffer-function' but i'm not sure...
I wrote in another posting that switch-to-buffer was one of the most
important advices in ECB; this is not correct - the advice of `display-buffer'
is at least equally important because it is needed to display all
stuff like help-buffers etc. automatically in the compile-window.

Here is small comment from ecb-layout.el:

;; This advice is the heart of the mechanism which displays all buffer in the
;; compile-window if they are are "compilation-buffers" in the sense of
;; `ecb-compilation-buffer-p'!
;; We do not use `display-buffer-function' but we just handle it within the
;; advice, because otherwise we would have to implement all window-choosing
;; for ourself and with our advice we just "restrict" the windows
;; `display-buffer' can use (by setting the not choosable windows temporarly
;; dedicated) but the real choosing-task is done by the function
;; itself - this is much better and smarter than implementing the whole stuff.

So displaying some buffers in certain windows automatically is very important
for a tool like ECB...of course there are hooks like `display-buffer-function'
which could be used instead of an advice but as described above (see the comment)
this implies to reimplement all standard window-choosing-stuff again which
is a bad idea and superfluous...

So what i'm still missing in the core-functionality of Emacs is a good
and smart concept to 'redirect' displaying certain buffer to certain windows.

> 
> - I broke an optimization, marked as FIXME in windows.c. It doesnt
>   look especially important so I wont not spend time on it until
>   everything works properly.

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

[martin rudalics]

 > So displaying some buffers in certain windows automatically is very important
 > for a tool like ECB...of course there are hooks like `display-buffer-function'
 > which could be used instead of an advice but as described above (see the comment)
 > this implies to reimplement all standard window-choosing-stuff again which
 > is a bad idea and superfluous...

I rewrote `display-buffer' in Elisp and - provided Stefan agrees - plan
to commit this soon.  In this case you wouldn't have to "rewrite" any of
its code but simply copy it and patch the necessary parts.

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

[klaus.berndl]

martin rudalics wrote:
>  > So displaying some buffers in certain windows automatically is
>  very important > for a tool like ECB...of course there are hooks
>  like `display-buffer-function' > which could be used instead of an
>  advice but as described above (see the comment) > this implies to
>  reimplement all standard window-choosing-stuff again which > is a
> bad idea and superfluous... 
> 
> I rewrote `display-buffer' in Elisp and - provided Stefan agrees -
> plan 
> to commit this soon.  In this case you wouldn't have to "rewrite" any
> of 
> its code but simply copy it and patch the necessary parts.

copying the whole stuff in an own `display-buffer-function' is not
the smartest approach - with XEmacs i have done exactly this because
XEmacs had an elisp display-buffer for a long time - but copying
these huge amount of code (in parts ugly code - at least the XEmacs-
version) into an own display-buffer-function and then finding(!!)
and then patching a very small portion for the ECB-needs is really
a pain - here IMHO is the choosen advice-approach of ECB much smarter
- but anyway: If you prefer a full functional copied and patched
display-buffer-function instead of a save and smart advice, it would
be fine for me... ;-)

Klaus

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

[martin rudalics]

 > copying the whole stuff in an own `display-buffer-function' is not
 > the smartest approach - with XEmacs i have done exactly this because
 > XEmacs had an elisp display-buffer for a long time - but copying
 > these huge amount of code (in parts ugly code - at least the XEmacs-
 > version) into an own display-buffer-function and then finding(!!)
 > and then patching a very small portion for the ECB-needs is really
 > a pain - here IMHO is the choosen advice-approach of ECB much smarter
 > - but anyway: If you prefer a full functional copied and patched
 > display-buffer-function instead of a save and smart advice, it would
 > be fine for me... ;-)

I don't understand: You can stuff the advice related code into
`display-buffer-function' and call the real `display-buffer' from there
(with `display-buffer-function' temporarily bound to nil).

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

[klaus.berndl]

martin rudalics wrote:
>  > copying the whole stuff in an own `display-buffer-function' is not
>  > the smartest approach - with XEmacs i have done exactly this
>  because > XEmacs had an elisp display-buffer for a long time - but
>  copying > these huge amount of code (in parts ugly code - at least
>  the XEmacs- > version) into an own display-buffer-function and then
>  finding(!!) > and then patching a very small portion for the
>  ECB-needs is really > a pain - here IMHO is the choosen
>  advice-approach of ECB much smarter > - but anyway: If you prefer a
>  full functional copied and patched > display-buffer-function instead
>  of a save and smart advice, it would > be fine for me... ;-)
> 
> I don't understand: You can stuff the advice related code into
> `display-buffer-function' and call the real `display-buffer' from
> there (with `display-buffer-function' temporarily bound to nil).

ok, you are right - i had this idea not in my mind...

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

[Stefan Monnier]

> I rewrote `display-buffer' in Elisp and - provided Stefan agrees - plan
> to commit this soon.

Yes, that would be good, except I haven't had time to test it.

> In this case you wouldn't have to "rewrite" any of
> its code but simply copy it and patch the necessary parts.

Well the "simply" part is misleading: it's a big piece of code and
copy&modify suffers from the usual problem of keeping the
code uptodate.  But in any case you shouldn't need `advice' on
display-buffer, you should be able to use
display-buffer-function instead.


        Stefan

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

[Richard M Stallman]

    I rewrote `display-buffer' in Elisp and - provided Stefan agrees - plan
    to commit this soon.  In this case you wouldn't have to "rewrite" any of
    its code but simply copy it and patch the necessary parts.

That is true, but I suspect that any features that ECB needs
are important enough to be worth adding to the standard definition
of `display-buffer'.  That should become easier once it is in Lisp.

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

[Richard M Stallman]

    - set "pin" to t, and the window will not go away on delete-other-winows

The name `pin' does not seem to relate to the meaning.  Would you
please pick a name that indicates what this does?

    - set "group" to something, and all windows with the same value will be
    considered in the same window group, which affects other-window for
    instance.

How does this affect other-window?

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

[joakim]

Richard M Stallman <rms@gnu.org> writes:

>     - set "pin" to t, and the window will not go away on delete-other-winows
>
> The name `pin' does not seem to relate to the meaning.  Would you
> please pick a name that indicates what this does?

I chose "pin" because in some gui toolkits there is a widget that looks
like a little needle/pin that you can use to "fasten" the window and not
go away on certain operations.

I dont have a better name than pin right now, can someone think one up?


>     - set "group" to something, and all windows with the same value will be
>     considered in the same window group, which affects other-window for
>     instance.
>
> How does this affect other-window?

c-x o only jumps between other windows with the same group id.

The main attraction of this is that it is possible to have a number of
context windows, and an edit area. Its not normaly interesting to select
one of the context windows, only windows in the edit area.

-- 
Joakim Verona

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

[Stefan Monnier]

> I chose "pin" because in some gui toolkits there is a widget that looks
> like a little needle/pin that you can use to "fasten" the window and not
> go away on certain operations.

> I dont have a better name than pin right now, can someone think one up?

I wouldn't worry about naming right now.  First we need to get the
design to work for something like ECB, Speedbar, etc..


        Stefan

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

[joakim]

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

>> I chose "pin" because in some gui toolkits there is a widget that looks
>> like a little needle/pin that you can use to "fasten" the window and not
>> go away on certain operations.
>
>> I dont have a better name than pin right now, can someone think one up?
>
> I wouldn't worry about naming right now.  First we need to get the
> design to work for something like ECB, Speedbar, etc..
>

I think this patch basically achieves what it set out to do now:

- "pinning" windows 
- "grouping" windows 

pinning and grouping together makes it possible to implement context
windows surrounding an edit area(much like the emacs gdb interface looks
like, but without the inconvenience that c-x 1 in the edit area
destroys the entire layout)

There are other things that are needed that I think are outside the scope of
this particular patch:

- making a set of buffers live in a particular context window, for
  instance compilation output should be configurable to always go to a
  special compilation output window. (I intuit this could be done at the
  elisp level with buffer local variables)

  Whatever interface is chosen could presumably also be used for tab
  support. 

- understand why the speedbar has to be a frame and make it possible to
  put it in a context window instead(The ECB does this already somehow)

  

>
>         Stefan
>
-- 
Joakim Verona

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

[Stefan Monnier]

>>> I chose "pin" because in some gui toolkits there is a widget that looks
>>> like a little needle/pin that you can use to "fasten" the window and not
>>> go away on certain operations.
>>> I dont have a better name than pin right now, can someone think one up?
>> I wouldn't worry about naming right now.  First we need to get the
>> design to work for something like ECB, Speedbar, etc..

> I think this patch basically achieves what it set out to do now:

> - "pinning" windows 
> - "grouping" windows 

> pinning and grouping together makes it possible to implement context
> windows surrounding an edit area(much like the emacs gdb interface looks
> like, but without the inconvenience that c-x 1 in the edit area
> destroys the entire layout)

It looks like that indeed provides what we need, but I wouldn't be
surprised if it's not good enough.  That's why I first want to see
someone use it for ECB.


        Stefan

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

[klaus.berndl]

Stefan Monnier wrote:
>>>> I chose "pin" because in some gui toolkits there is a widget that
>>>> looks like a little needle/pin that you can use to "fasten" the
>>>> window and not go away on certain operations.
>>>> I dont have a better name than pin right now, can someone think
>>>> one up? 
>>> I wouldn't worry about naming right now.  First we need to get the
>>> design to work for something like ECB, Speedbar, etc..
> 
>> I think this patch basically achieves what it set out to do now:
> 
>> - "pinning" windows
>> - "grouping" windows
> 
>> pinning and grouping together makes it possible to implement context
>> windows surrounding an edit area(much like the emacs gdb interface
>> looks like, but without the inconvenience that c-x 1 in the edit area
>> destroys the entire layout)
> 
> It looks like that indeed provides what we need, but I wouldn't be
> surprised if it's not good enough.  That's why I first want to see
> someone use it for ECB.

well, let me try to write down the requirements specification from
the point of view of ECB...

BTW: currently the docstring of `window-list doesn't mention the ordering
of the result-list... Is there any reliable ordering?  IMHO especially
window-layout-engines like ECB needs a well defined ordering of the
window-list in their frame...Currently window-list seems to return a well
ordered list (the order next-window would go) and ECB uses and needs this.
But could this be documented? Would be great...

Klaus

> 
> 
>         Stefan

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

[Richard M Stallman]

    I think this patch basically achieves what it set out to do now:

    - "pinning" windows 
    - "grouping" windows 

Perhaps C-x ^ should only transfer lines to or from other windows
in the same group.  I think that is what people will expect,
for the likely uses of this feature.

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

[Richard M Stallman]

    I chose "pin" because in some gui toolkits there is a widget that looks
    like a little needle/pin that you can use to "fasten" the window and not
    go away on certain operations.

That is horribly cryptic and unclear.  We should rename it before
installing it.

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

[Miles Bader]

Richard M Stallman <rms@gnu.org> writes:
>     I chose "pin" because in some gui toolkits there is a widget that looks
>     like a little needle/pin that you can use to "fasten" the window and not
>     go away on certain operations.
>
> That is horribly cryptic and unclear.  We should rename it before
> installing it.

It's a pretty common term for this usage though.  [A related example is
"pinning" memory to prevent it from being paged out.]

-Miles

-- 
Year, n. A period of three hundred and sixty-five disappointments.

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

[Richard M Stallman]

    >     I chose "pin" because in some gui toolkits there is a widget that looks
    >     like a little needle/pin that you can use to "fasten" the window and not
    >     go away on certain operations.
    >
    > That is horribly cryptic and unclear.  We should rename it before
    > installing it.

    It's a pretty common term for this usage though.

I had never heard it before, so it can't be that common.

						      [A related example is
    "pinning" memory to prevent it from being paged out.]

That is normally called "locking" the page.

I suggest `nodelete' or `preserve' for this property.



On the other hand, maybe the proper implementation of window groups
will make this unnecessary.  If `delete-other-windows' only deletes
windows in the same group as the selected window, does that take
care of this?