[Top][All Lists]
[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.
- window groups, martin rudalics, 2008/05/28
- Re: window groups, Richard M Stallman, 2008/05/28
- Re: window groups, martin rudalics, 2008/05/29
- Re: window groups, Stefan Monnier, 2008/05/29
- Re: window groups, martin rudalics, 2008/05/30
- Re: window groups, Stefan Monnier, 2008/05/30
- Re: window groups, martin rudalics, 2008/05/30
- Re: window groups, Stefan Monnier, 2008/05/31
- Re: window groups, martin rudalics, 2008/05/31
- Re: window groups, Richard M Stallman, 2008/05/29
- Re: window groups,
martin rudalics <=
- Re: window groups, Richard M Stallman, 2008/05/29
- Re: window groups, martin rudalics, 2008/05/30
- Re: window groups, Richard M Stallman, 2008/05/30
- Re: window groups, Daniel Colascione, 2008/05/31
- Re: window groups, Miles Bader, 2008/05/31
- Re: window groups, martin rudalics, 2008/05/31
Re: window groups, Chong Yidong, 2008/05/29
Re: window groups, Chong Yidong, 2008/05/29