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