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

[Eric M. Ludlam]

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

Eric

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