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: Mon, 27 Jul 2009 09:06:02 -0700 Message-ID: <1248710762.6165.28.camel@dell-desktop.example.com> References: <20090712180623.GA1009@muc.de> <4A643993.5080302@gmx.at> <87ljmjl9ow.fsf@catnip.gol.com> <4A648E1D.1000007@gmx.at> <877hy3l3kj.fsf@catnip.gol.com> <4A64BF58.4030001@gmx.at> <871vobkny7.fsf@catnip.gol.com> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248714079 2715 80.91.229.12 (27 Jul 2009 17:01:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 17:01:19 +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 Mon Jul 27 19:01:08 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 1MVTZU-00012R-3e for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 19:01:08 +0200 Original-Received: from localhost ([127.0.0.1]:50514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVTZT-0000BM-Kd for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 13:01:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVSiM-0004Ke-Uv for emacs-devel@gnu.org; Mon, 27 Jul 2009 12:06:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVSiH-0004BH-Th for emacs-devel@gnu.org; Mon, 27 Jul 2009 12:06:14 -0400 Original-Received: from [199.232.76.173] (port=53935 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVSiH-0004Al-K9 for emacs-devel@gnu.org; Mon, 27 Jul 2009 12:06:09 -0400 Original-Received: from smtp161.iad.emailsrvr.com ([207.97.245.161]:52084) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MVSiE-0001xZ-Qh; Mon, 27 Jul 2009 12:06:07 -0400 Original-Received: from relay26.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay26.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 98F7A1B40A2; Mon, 27 Jul 2009 12:06:05 -0400 (EDT) Original-Received: by relay26.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id B668F1B400B; Mon, 27 Jul 2009 12:06:03 -0400 (EDT) In-Reply-To: <4A6D4BE3.9080102@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:113228 Archived-At: On Mon, 2009-07-27 at 08:40 +0200, martin rudalics wrote: > `next-window' has a MINIBUF and an ALL-FRAMES argument. I'm not sure > whether and how their semantics would change with nested frames. Ok. One interesting case might be `compare-windows', as follows: * Current behavior I've two visible frames, one window each - I run `compare-windows'. The comparison will be between the two windows in the visible frames. * After behavior With no changes to `next-window', assume that I have two frames. In each frame there is but one edit-area window. However, the selected frame also has a visible control panel frame. One of the two visible edit areas is the current window. Depending on where in the frame list the control panel is, `compare-windows' might compare the two edit area windows or it might compare an edit area window to a control panel window. At first glance, that sounds bad and, in that sense, you have a good point. Where I think you're off is in the notion to fix that by changing `next-window'. The problem is that sometimes it will be The Right Thing to compare the two edit area windows and other times it will be TRT to compare an edit area window with a control panel window. It really depends on what the user wants to do and on what is displayed in each window. The order of windows per `next-window' can't depend on "what the user means when invoking the current command". That is why `compare-windows' already contains two calls to `next-window' with various parameters. It calls `next-window' one way and finds out if the result "makes sense" for the `compare-windows' function. If not, it tries calling `next-window' a different way and again checks if the result "makes sense". My conclusion is that IF users are unhappy with what `compare-windows' does after control panels are introduced, then it is `compare-windows' rather than `next-window' that has to change. And that's a big IF, it's not a forgone conclusion that people will be unhappy with the interaction of control panels and the existing `compare-windows' code. Note that nothing about "framelets" vs. "window groups" changes this conclusion: with EITHER approach, the question of whether and how to modify the window-selection logic in `compare-windows' still comes up. Another function with similar issues would be `server-switch-buffer'. If the default logic for selecting a window in which to display the buffer requested via the server returns a minibuffer window, `next-window' is used to find a better window. It is conceivable that it might wind up picking a control panel window when an edit area window is more desirable. (Equally conceivable that a control panel window might be more desirable.) However, the existing logic in `server-switch-buffer' to honor `window-dedicated-p' looks as if it would handle this case properly, provided that programs `set-window-dedicated' for control panel windows that shouldn't be casually re-used. In any event, there is no single change to `next-window' that would DTRT for all cases of either `compare-windows' or `server-switch-buffer' and no change to `next-window' that would be right for both functions. It looks more like IF, in practice, the default behaviors of those functions have to change then the logic in those functions themselves has to change. > >> > Maybe. There are other possibilities. > >> > It could also be done with something like > >> > the layout engines found in some GUI > >> > toolkits. > >> > >> These would have to be rewritten and adapted accordingly. > > > > It shouldn't be very much code. > > Fine. This might also help frame resizing code DTRT in general. I'm not sure what problem with frame resizing you are referring to but, ok. > Maybe it would be simpler to call framelets just frames and the "outer" > (nil-parent) frame something different so there would be no changes in > the naming conventions. I don't want to confuse this immediate discussion with new names for the same thing but... I would say they are all simply "frames". Perhaps a good name for a frame with a nil parent is a "primary frame". One with a non-nil parent is an "attached frame". (frame-p a-primary-frame) => t (frame-p an-attached-frame) => t (frame-attached-p primary) => nil (frame-attached-p attached) => a-primary-frame Analogous to `window-dedicated-p' but with no corresponding `set-*' function (yet?). -t