From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: window groups Date: Fri, 30 May 2008 07:33:11 +0900 Message-ID: <874p8gkafs.fsf@catnip.gol.com> References: <483D4E9A.9020001@gmx.at> <87wsldgkgz.fsf@stupidchicken.com> <87abi9j57j.fsf@catnip.gol.com> <87ve0wbxhb.fsf@stupidchicken.com> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1212100448 29757 80.91.229.12 (29 May 2008 22:34:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2008 22:34:08 +0000 (UTC) Cc: martin rudalics , emacs-devel To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 30 00:34:47 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K1qhL-0003z8-Q0 for ged-emacs-devel@m.gmane.org; Fri, 30 May 2008 00:34:16 +0200 Original-Received: from localhost ([127.0.0.1]:49463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1qgZ-0003ll-Uf for ged-emacs-devel@m.gmane.org; Thu, 29 May 2008 18:33:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1qgV-0003lW-J9 for emacs-devel@gnu.org; Thu, 29 May 2008 18:33:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1qgT-0003ko-Nu for emacs-devel@gnu.org; Thu, 29 May 2008 18:33:22 -0400 Original-Received: from [199.232.76.173] (port=47586 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1qgT-0003kl-Jt for emacs-devel@gnu.org; Thu, 29 May 2008 18:33:21 -0400 Original-Received: from smtp12.dentaku.gol.com ([203.216.5.74]:33341) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1qgO-0000yQ-5N; Thu, 29 May 2008 18:33:16 -0400 Original-Received: from 218.231.109.189.eo.eaccess.ne.jp ([218.231.109.189] helo=catnip.gol.com) by smtp12.dentaku.gol.com with esmtpa (Dentaku) id 1K1qgL-0002Cr-C2; Fri, 30 May 2008 07:33:13 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id DAB2D2F3A; Fri, 30 May 2008 07:33:11 +0900 (JST) System-Type: i686-pc-linux-gnu In-Reply-To: <87ve0wbxhb.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 29 May 2008 17:40:16 -0400") Original-Lines: 56 X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:98019 Archived-At: Chong Yidong 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.