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

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

[Eric M. Ludlam]

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

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

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

Eric

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

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?

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)

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

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

[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