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

[Eric M. Ludlam]

>>> <address@hidden> seems to think that:
>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?

My concern is not that good window parameters which are ECB
independent and make ECB implementable without advice can't be
devised.  A do agree your current tactics have read to me as
independent of ECB.

My concern is that the implementation won't scale.  A user keystroke
command combination may keep ECB windows independent of manipulation,
but once this API is available new programs will not be affected this
way.  There will still be window walking APIs that someone may write
that doesn't account for ECB or Speedbar, or some other tool using
these features.

A good example is the mode line and header line.  The mode line came
with a defined pattern.  Major modes manipulate the big part, and
there are key insertion points for minor modes, etc.  Everyone gets
along ok there.

The header line appeared, but has no accounting for it's use.  You now
have to choose between Tabbar tabs, or Semantic's sticky-function
mode.  They just don't work together.

I expect what is needed to keep ECB independent of other similar
layout apps is to either pre-define a use pattern the way mode-line
does, or make sure the API enforces independence between multiple
users of the API.

Since the focus is about IDE like behavior, I think a better approach
would be that ECB would cease being "a big browser", and change
instead into a collection of useful plugins/tools/apps/thingies.  In
this way, ECB's file browser, tag browser, history browser are all
just little apps, and there is a core Emacs facility for doing a
layout of these little browser window things.  Speedbar would then
just become one of these independent browser things.

By way of example, you can do this now with frames.  If all of ECB's
window types were put in little frames of the desired size, they are
independent of each other, the edit area, and of speedbar.  What it's
missing is the nice logical layout.

It very well could be that the ECB layout engine would become the
Emacs facility for doing this layout.  What's important is to also
make sure independent tools, using the same API, won't stomp on
each other.

Is this more clear?
Eric

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