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: Infrastructural complexity. Date: Tue, 21 Jul 2009 07:08:00 +0900 Message-ID: <871vobkny7.fsf@catnip.gol.com> References: <20090712180623.GA1009@muc.de> <1247793496.6302.112.camel@dell-desktop.example.com> <1247797261.6302.137.camel@dell-desktop.example.com> <1247798678.6302.156.camel@dell-desktop.example.com> <87ocrjtafd.fsf@stupidchicken.com> <1247871746.6287.157.camel@dell-desktop.example.com> <1247966060.7410.63.camel@dell-desktop.example.com> <4A62F7AD.4000609@gmx.at> <87eiscn223.fsf@catnip.gol.com> <4A643993.5080302@gmx.at> <87ljmjl9ow.fsf@catnip.gol.com> <4A648E1D.1000007@gmx.at> <877hy3l3kj.fsf@catnip.gol.com> <4A64BF58.4030001@gmx.at> 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 1248127714 19269 80.91.229.12 (20 Jul 2009 22:08:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jul 2009 22:08:34 +0000 (UTC) Cc: Thomas Lord , rms@gnu.org, cyd@stupidchicken.com, lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, juri@jurta.org, monnier@iro.umontreal.ca, acm@muc.de, drew.adams@oracle.com To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 21 00:08:25 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 1MT121-0003uM-5o for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 00:08:25 +0200 Original-Received: from localhost ([127.0.0.1]:60041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT120-0001nt-JA for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 18:08:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MT11v-0001no-Qq for emacs-devel@gnu.org; Mon, 20 Jul 2009 18:08:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MT11q-0001nT-W5 for emacs-devel@gnu.org; Mon, 20 Jul 2009 18:08:19 -0400 Original-Received: from [199.232.76.173] (port=49878 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT11q-0001nO-Su for emacs-devel@gnu.org; Mon, 20 Jul 2009 18:08:14 -0400 Original-Received: from smtp12.dentaku.gol.com ([203.216.5.74]:47368) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MT11m-0004r3-8P; Mon, 20 Jul 2009 18:08:10 -0400 Original-Received: from 218.231.109.150.eo.eaccess.ne.jp ([218.231.109.150] helo=catnip.gol.com) by smtp12.dentaku.gol.com with esmtpa (Dentaku) id 1MT11d-00060S-Sa; Tue, 21 Jul 2009 07:08:01 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 035B9DF6F; Tue, 21 Jul 2009 07:08:00 +0900 (JST) System-Type: x86_64-unknown-linux-gnu In-Reply-To: <4A64BF58.4030001@gmx.at> (martin rudalics's message of "Mon, 20 Jul 2009 21:02:48 +0200") Original-Lines: 59 X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com 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:112866 Archived-At: >> AFAIK, the problem people are trying to solve right now is a way of >> increasing the power of emacs _automatic_ control over window layout -- >> burdening the user with the placement and moving of these sub-windows is >> exactly what we _don't_ want to do. > > In my book tearing off a window does not count as automatic control. Why do you keep talking about "tear-off windows"? They aren't the focus of this discussion. As I said in my previous message: [[I don't know if "tear off" windows are a goal or not, but tearing off a emacs sub-window is an explicit user action saying "ok, I as user am now assuming control over this sub-window."']] In other words, they are (1) not a required feature, and (2) represent and explicit user _escape_ from the automatic layout. The focus of this discussion -- AFAICT -- is the automatic layout _not_ the optional-and-fringe-feature of tear-off-windows. While tear-off windows may be an interesting feature, and kinda cool, they are not a particularly important feature, and are _not_ the point of the current conversation. It'd be fine if whatever solution is decided completely lacks that feature. >> They certainly don't do it well, not if you want application-specific >> inter-relationships between a set of different windows (which is exactly >> what we want). > > What's the purpose of tiling window managers when you can't tell them > _where_ to put your windows? [completely OT at this point, but: to place windows. By default, most tiling WMs, do so automatically, unless the user or the app takes the trouble to setup some (non-default and WM-specific) mechanism to do so.] > Tearing off a window and putting it into a separate frame is no synonym > for "moving" that window into a separate frame. You have to make a new > window and you break all overlays with a 'window property in the old > window's buffer and all references to that window stored in running > applications (although for the user the new window appears the same as > before). So if you consider tearing off windows "a natural thing to do" > you only raise false hopes. I dunno; I haven't looked at the implementation details. It doesn't sound particularly hard to me, offhand, to have the Emacs code move an internal Emacs window structure to another parent frame (preserving any pointers/whatever, but changing the frame pointer etc) in this case, but I'll have to demur from arguing about it, since I don't have any detailed basis on which do so. Since tear-off windows are not very important though, it doesn't really matter. An implementation which creates a new Emacs window inside a new frame seems acceptable to me as well. Or simply not having tear-off windows. -Miles -- Learning, n. The kind of ignorance distinguishing the studious.