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

["Eric M. Ludlam" <eric@siege-engine.com>]

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