Re: window groups

[Miles Bader]

Chong Yidong <address@hidden> writes:
>>> It seems to me that, in practice, any Elisp application that needs to
>>> control the window configuration will probably want to control over the
>>> entire frame.  Otherwise, the resulting windows will likely be too
>>> small.  WDYT?
>>
>> Do you have any support for such an assumption?  It seems wrong to me,
>> simply based on personal experience.
>
> I'm not sure.  But look at the typical Emacs frame where you're running
> Gnus, with the frame is divided into a summary window and an article
> window.  Is there any space left for, e.g., a GDB session?  On my
> machine, if the GDB session were to split the Gnus article window and
> squeeze its windows in there, I wouldn't be able to see much in those
> windows.

I think the main issue is not multiple giant apps running in the same
frame[*], but rather:

 (1) Little special purpose windows that you want in particular places,
     and want to protect from being stomped on by other activities
     (whether normal editing or a special-purpose app such as Gnus).

     The most common example would be an in-frame speedbar, which is
     something people (including me) want, but which is not offered by
     the version of speedbar in Emacs because it just doesn't work well
     with Emacs' primitive management of in-frame windows.

     Another example might be something like an Emacs audio player,
     which you might want to always occupy a 1-line window at the
     bottom of your frame.

 (2) When one _is_ inside an Emacs app that tries to maintain a certain
     window arrangement, the handling of window management outside the
     domain of that app.

     For instance, you're in Gnus or whatever, and ask for help, where
     should the window showing the help buffer go?


[*]  Though I don't think this case should be ignored -- there _are_
     people who run Emacs in large windows and prefer to use Emacs
     windows for management rather than frames.


[I don't know offhand whether Martin's proposal is the best way to deal
with these issues (I found the writeup a bit hard to digest), but when
I've thought about this sort of thing before, my thoughts tended towards
making the existing Emacs window tree more visible to lisp code, and
adding some mechanism for specifying where in the tree various
operations would be directed by default.]

-Miles

-- 
Learning, n. The kind of ignorance distinguishing the studious.