emacs-devel
[Top][All Lists]
Advanced

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

Re: window groups


From: martin rudalics
Subject: Re: window groups
Date: Fri, 30 May 2008 09:08:34 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

>     One of the problems of integrating ECB into Emacs is to avoid that
>     "other" Emacs operations interfere with those of ECB (where other
>     operations include popping up a *help*, *info*, or *backtrace* window).
>
> This is an attempt to design a feature to distinguish between the
> "editing area" and other add-ons, it seems.  Is that right?

It's merely keeping apart IDE specific objects like the editing area or
the IDE's own help system from Emacs specific *help* or *info* buffers.

> But it also attempts to generalize this by allowing for more than one
> group.  Do you see a scenario in which having more than one window
> group in one frame would be used?

All IDEs I know of use just one edit area.  Stefan mentioned that view
areas could be considered a group as well and there are some ECB layouts
where views are split both horizontally _and_ vertically.  In that case
using groups within the view area might be useful.

> Without such a scenario, we have no
> basis to think about what operations ought to do in such a case, and thus
> no basis for the generalization.

One scenario is that of multiple speedbar/window combinations appearing
simultaneously on a frame.  Every such combination would form a separate
window group.

> Based on what you've said, it seems that there are three kinds of
> buffers that might appear in something like ECB.  (I am partly guessing,
> since I have not seen ECB itself.)

I'm guessing as well.

> * File buffers
>
> * Special buffers of ECB
>
> * Other buffers such as *Help*, *Info*, and so on.
>
> I think the right way to design this feature is to figure out the
> right thing to do with windows for these three kinds of buffers,
> and then design an interface to request that.

Yes.

> But we should not try to make it any more general than that
> until we have use cases to guide our thinking about them.
>
>     By default `display-buffer' does not invoke `split-window' with GROUP
>     set to t - hence these windows always appear outside the rectangular
>     ares reserved for group windows.  The same holds for any application
>     that is not aware of the group the selected window belongs to.
>
>     ...
>
>     Interactively, `split-window-horizontally' and `split-window-vertically'
>     would call `split-window' with GROUP set to t iff WINDOW is part of a
>     group.
>
> What about C-x 4 C-f?  If you do that inside ECB, should the new window
> be part of the ECB group?

I think so but it should be customizable.  The default value would have
to be decided individually for each function.





reply via email to

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