From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Wed, 29 Jul 2009 12:22:01 -0700 Message-ID: <1248895321.5922.54.camel@dell-desktop.example.com> References: <20090712180623.GA1009@muc.de> <4A658CD2.8020504@gmx.at> <1248195599.7551.26.camel@dell-desktop.example.com> <4A65FA0E.6020800@gmx.at> <1248200131.7551.75.camel@dell-desktop.example.com> <4A66E607.9030505@gmx.at> <1248280114.7109.33.camel@dell-desktop.example.com> <4A67593D.6020908@gmx.at> <1248289454.7109.47.camel@dell-desktop.example.com> <4A682C53.2080307@gmx.at> <1248375083.15583.9.camel@dell-desktop.example.com> <4A6970B8.7000006@gmx.at> <4A6AC7EA.2010007@gmx.at> <4A6B3CE2.8070404@gmx.at> <4A6C72BE.5080207@gmx.at> <1248628716.5952.11.camel@dell-desktop.example.com> <4A6C961E.3030805@gmx.at> <1248633292.5952.21.camel@dell-desktop.example.com> <4A6D4BE3.9080102@gmx.at> <1248710762.6165.28.camel@dell-desktop.example.com > <4A6DDB8D.2070601@gmx.at> <1248717944.6165.47.camel@dell-desktop.example.com> <4A6EAAE4.3090309@gmx.at> <1248794312.5971.7.camel@dell-desktop.example.com> <4A7010F8.90308@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248896020 7207 80.91.229.12 (29 Jul 2009 19:33:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2009 19:33:40 +0000 (UTC) Cc: rms@gnu.org, cyd@stupidchicken.com, lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, juri@jurta.org, Stefan Monnier , acm@muc.de, drew.adams@oracle.com, Miles Bader To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 29 21:33:31 2009 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 1MWEu2-0004AE-NS for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2009 21:33:31 +0200 Original-Received: from localhost ([127.0.0.1]:42988 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWEu2-0002pY-5T for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2009 15:33:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWEof-0003D6-Ru for emacs-devel@gnu.org; Wed, 29 Jul 2009 15:27:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWEob-00037X-Q6 for emacs-devel@gnu.org; Wed, 29 Jul 2009 15:27:57 -0400 Original-Received: from [199.232.76.173] (port=38682 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWEob-00036z-HI for emacs-devel@gnu.org; Wed, 29 Jul 2009 15:27:53 -0400 Original-Received: from smtp231.iad.emailsrvr.com ([207.97.245.231]:35529) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MWEoZ-00062f-VG; Wed, 29 Jul 2009 15:27:52 -0400 Original-Received: from relay13.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id D10451CE5E6; Wed, 29 Jul 2009 15:22:03 -0400 (EDT) Original-Received: by relay13.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id E42E71CC66D; Wed, 29 Jul 2009 15:22:01 -0400 (EDT) In-Reply-To: <4A7010F8.90308@gmx.at> X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:113353 Archived-At: On Wed, 2009-07-29 at 11:06 +0200, martin rudalics wrote: > >> It wouldn't be too difficult to make Emacs windows only exist within > >> "attached frames" aka as frames. > > > > I agree that that would not be difficult. > > I think, however, that that would be a mistake > > in the design. In every window system window > > there should be a set of Emacs windows for which > > the selected frame corresponds to the window > > system window. If one of those Emacs windows > > is selected then minimizing the corresponding > > frame (etc.) should have its effect on the window > > system window (and by extension on any "attached > > frames"). > > The `window-frame' of any window would be an attached frame that has an > associated primary window aka window-system window. Why would that be a > mistake in the design? Let's talk it through. Perhaps you can change my mind though I still think it is a mistake. In your system, a window system window corresponds to a frame for which most properties are ignored. The edit area and all control panels are separate frames, nested in that outer frame. In mine, the edit area frame is the frame of the window system window while the control panels are separate frames, nested in that edit area frame. Consider a command like `delete-frame'. If invoked within a control panel, we'd like it to kill the windows in the control panel and make the control panel invisible. (Perhaps its frame object is then a dead frame or perhaps not.) If invoked in the edit area, we'd like it to kill all of the frames found within the window system window, and for that window system window to go away. How can differences like that most naturally be explained? I think it's by making the window system window frame and the edit area frame one in the same thing. Similarly, let's suppose that in a control panel I turn on the toolbar. We want the toolbar to appear in just that control panel. On the other hand, turning on a toolbar in the edit area should create a toolbar that runs across the entire window system window. So, again, it's natural to identify the edit area frame with the window system window frame. > > The "edit area" frame should, at least from > > the perspective of elisp and interactive > > commands, be "the frame which corresponds to > > the window system window". > If the edit-area frame is an attached frame it doesn't correspond to a > window-system window. If it's a primary frame the size of its windows > don't sum up to its size. What am I missing? It doesn't sum to the size of the frame, that's true. Isn't it already the case, however, that the window widths and heights don't necessarily add up to the full size of the frame? What are you worried about? -t > martin