From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Thu, 30 Jul 2009 11:07:27 +0200 Message-ID: <4A7162CF.6030209@gmx.at> References: <20090712180623.GA1009@muc.de> <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> <1248895321.5922.54.camel@dell-desktop.example.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248944883 27625 80.91.229.12 (30 Jul 2009 09:08:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2009 09:08:03 +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: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 30 11:07:54 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 1MWRc9-0001Wz-Av for ged-emacs-devel@m.gmane.org; Thu, 30 Jul 2009 11:07:53 +0200 Original-Received: from localhost ([127.0.0.1]:57052 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWRc8-0003EV-NI for ged-emacs-devel@m.gmane.org; Thu, 30 Jul 2009 05:07:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWRc4-0003EL-28 for emacs-devel@gnu.org; Thu, 30 Jul 2009 05:07:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWRbz-0003Dz-Hj for emacs-devel@gnu.org; Thu, 30 Jul 2009 05:07:47 -0400 Original-Received: from [199.232.76.173] (port=35329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWRby-0003Dj-UZ for emacs-devel@gnu.org; Thu, 30 Jul 2009 05:07:43 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:44988) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MWRbt-0002Bz-Av for emacs-devel@gnu.org; Thu, 30 Jul 2009 05:07:42 -0400 Original-Received: (qmail invoked by alias); 30 Jul 2009 09:07:34 -0000 Original-Received: from 62-47-54-224.adsl.highway.telekom.at (EHLO [62.47.54.224]) [62.47.54.224] by mail.gmx.net (mp040) with SMTP; 30 Jul 2009 11:07:34 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19C+IReLTFC0KF6YUMryWgcbEfdXTPhsisSWlvUBH 78PA1H9fLZCNOP User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <1248895321.5922.54.camel@dell-desktop.example.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 X-detected-operating-system: by monty-python.gnu.org: GNU/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:113389 Archived-At: > 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? For example `window-full-width-p' is currently calculated as #define WINDOW_FULL_WIDTH_P(W) \ (WINDOW_TOTAL_COLS (W) == FRAME_TOTAL_COLS (WINDOW_XFRAME (W))) This would fail with your approach when invoked on a window in the edit area. We'd probably have to redefine it by asking whether that window is as wide as the root window of its frame. But such things haven't been investigated on a wide scale yet and we'd also have to cope with the somewhat paradoxical situation that the root window of a frame is no longer as wide as the containing frame. You haven't yet sketched the details of how your approach would handle things like `set-frame-position' or `set-frame-size'. IIUC you have to intercept these functions in some sense to handle the case where someone wants to move or resize an attached frame. I also have no idea how functions that let a user resize attached frames with the mouse and how mouse tracking in general will be implemented with nested frames. For example, if in your _______ |_|_|_| template |_|_|_| |_|_|_| I have the two attached frames named 1 and 2 as this: _______ |_|_|1| template |_|_|2| |_|_|_| What happens if I "move" the imaginary border between 1 and 2 up or down (provided I can do that at all). Does that also resize the edit area? Also an application might want to know whether the coordinates returned by `mouse-position' refer to the upper-left corner of the edit area or the primary frame. If they refer to the upper-left corner of the primary frame, we probably have to, for each primary frame, specify the offset of the root window of that frame (the upper-left corner of the edit area) in order to be able to determine in which window of the edit area the mouse is (provided the edit area can be split). OTOH how would `set-mouse-position' invoked on a primary frame interpret its X Y arguments? Could this move the mouse to an attached frame? I understand that you are mostly concerned with user visible functions like `delete-frame' or `other-frame' DTRT without changing them. But having `delete-frame' DTRT wrt whether its argument is the edit area or an(other) attached frame is trivial. If you specify that a primary frame can't live without an edit area, it goes without saying that if you delete the attached frame constituting the edit area, this will delete the containing primary frame too. Changing the underlying functions is the hard thing. If you eventually come up with a sketch of how you want to address issues like the ones I sketched above I might be able to tell you more. martin