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 01:30:36 +0900 Message-ID: <877hy3l3kj.fsf@catnip.gol.com> References: <20090712180623.GA1009@muc.de> <1247787842.6302.90.camel@dell-desktop.example.com> <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> 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 1248107469 17910 80.91.229.12 (20 Jul 2009 16:31:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jul 2009 16:31:09 +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 Mon Jul 20 18:31:00 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 1MSvlS-00046r-GZ for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 18:30:58 +0200 Original-Received: from localhost ([127.0.0.1]:48398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSvlR-0001iP-Uv for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 12:30:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MSvlM-0001hb-TZ for emacs-devel@gnu.org; Mon, 20 Jul 2009 12:30:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MSvlI-0001hP-IU for emacs-devel@gnu.org; Mon, 20 Jul 2009 12:30:52 -0400 Original-Received: from [199.232.76.173] (port=44328 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSvlI-0001hM-Eq for emacs-devel@gnu.org; Mon, 20 Jul 2009 12:30:48 -0400 Original-Received: from smtp12.dentaku.gol.com ([203.216.5.74]:42481) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MSvlE-0006Yz-Tp; Mon, 20 Jul 2009 12:30:45 -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 1MSvl6-0003sd-Mi; Tue, 21 Jul 2009 01:30:36 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 1AC70DF6F; Tue, 21 Jul 2009 01:30:36 +0900 (JST) System-Type: x86_64-unknown-linux-gnu In-Reply-To: <4A648E1D.1000007@gmx.at> (martin rudalics's message of "Mon, 20 Jul 2009 17:32:45 +0200") Original-Lines: 39 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:112835 Archived-At: martin rudalics writes: >> Once you start letting the WM have any control all bets are off -- >> remember, it's _not_ just initial placement, but movement, sizing >> [think: tiling WM!], additional WM-added frames, dealing with the many, >> many, differences between WMs on different platforms, etc. > > The user is supposed to control the WM 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. > and tiling WMs should manage multiple Emacs frames better than Emacs > itself is able to tile a frame into multiple windows. After all > that's what tiling WMs are supposed to do well. 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). [They do an OK job of laying out completely independent application windows in some case, at least to a point.] > So once we decided that the multi-frames approach is a non-starter we > should decide that tear-off windows and windows with menu- or toolbars > are non-starters too. Can we agree on that? 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." So _moving_ a torn-off emacs internal window into its own separate frame would actually be the most natural thing to do. -Miles -- "Whatever you do will be insignificant, but it is very important that you do it." Mahatma Gandhi