From: Miles Bader <miles@gnu.org>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: martin rudalics <rudalics@gmx.at>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: window groups
Date: Fri, 30 May 2008 07:33:11 +0900 [thread overview]
Message-ID: <874p8gkafs.fsf@catnip.gol.com> (raw)
In-Reply-To: <87ve0wbxhb.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 29 May 2008 17:40:16 -0400")
Chong Yidong <cyd@stupidchicken.com> 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.
next prev parent reply other threads:[~2008-05-29 22:33 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-28 12:22 window groups martin rudalics
2008-05-29 1:39 ` Richard M Stallman
2008-05-29 9:26 ` martin rudalics
2008-05-29 16:30 ` Stefan Monnier
2008-05-30 7:05 ` martin rudalics
2008-05-30 13:58 ` Stefan Monnier
2008-05-30 19:27 ` martin rudalics
2008-05-31 4:52 ` Stefan Monnier
2008-05-31 9:10 ` martin rudalics
2008-05-30 0:59 ` Richard M Stallman
2008-05-30 7:08 ` martin rudalics
2008-05-31 2:07 ` Richard M Stallman
2008-05-31 6:17 ` Daniel Colascione
2008-05-31 7:09 ` Miles Bader
2008-05-31 9:10 ` martin rudalics
2008-05-30 0:59 ` Richard M Stallman
2008-05-30 7:08 ` martin rudalics
2008-05-29 15:18 ` Chong Yidong
2008-05-30 7:06 ` martin rudalics
2008-05-29 16:10 ` Chong Yidong
2008-05-29 19:11 ` Miles Bader
2008-05-29 21:40 ` Chong Yidong
2008-05-29 22:33 ` Miles Bader [this message]
2008-05-29 23:53 ` Thomas Lord
2008-05-30 7:07 ` martin rudalics
2008-05-30 16:42 ` Thomas Lord
2008-05-30 16:08 ` Stefan Monnier
2008-05-31 9:10 ` martin rudalics
2008-05-31 11:52 ` Juanma Barranquero
2008-05-31 13:36 ` martin rudalics
2008-05-31 17:22 ` Thomas Lord
2008-05-31 22:37 ` martin rudalics
2008-06-02 3:49 ` Thomas Lord
2008-06-02 9:34 ` martin rudalics
2008-06-02 21:32 ` Thomas Lord
2008-06-03 5:52 ` Miles Bader
2008-06-03 9:02 ` martin rudalics
2008-06-03 9:51 ` René Kyllingstad
2008-06-03 11:26 ` martin rudalics
2008-06-03 11:54 ` Stephen Berman
2008-06-03 13:21 ` René Kyllingstad
2008-06-08 2:39 ` Stefan Monnier
2008-08-18 15:37 ` René Kyllingstad
2008-05-30 7:07 ` martin rudalics
2008-05-30 7:07 ` martin rudalics
2008-05-30 7:07 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874p8gkafs.fsf@catnip.gol.com \
--to=miles@gnu.org \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).