[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: klaus.berndl
Subject: RE: patch for optional inhibit of delete-other-windows(IDE feature)
Date: Wed, 30 Apr 2008 12:47:12 +0200

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


>         Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]