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

[klaus.berndl]

Eric M. Ludlam wrote:
>>>> Richard M Stallman <address@hidden> 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