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: Tue, 21 Jul 2009 11:39:30 +0200 Message-ID: <4A658CD2.8020504@gmx.at> 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> <871vobkny7.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248169260 16770 80.91.229.12 (21 Jul 2009 09:41:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jul 2009 09:41:00 +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: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 21 11:40:51 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 1MTBq6-0007k3-JB for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 11:40:51 +0200 Original-Received: from localhost ([127.0.0.1]:44181 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTBq5-0003Lt-TJ for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 05:40:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTBp0-0002B2-0M for emacs-devel@gnu.org; Tue, 21 Jul 2009 05:39:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTBou-00028w-JY for emacs-devel@gnu.org; Tue, 21 Jul 2009 05:39:40 -0400 Original-Received: from [199.232.76.173] (port=37913 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTBou-00028q-Cz for emacs-devel@gnu.org; Tue, 21 Jul 2009 05:39:36 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:45244) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MTBot-0003ZS-M0 for emacs-devel@gnu.org; Tue, 21 Jul 2009 05:39:36 -0400 Original-Received: (qmail invoked by alias); 21 Jul 2009 09:39:32 -0000 Original-Received: from 62-47-50-31.adsl.highway.telekom.at (EHLO [62.47.50.31]) [62.47.50.31] by mail.gmx.net (mp047) with SMTP; 21 Jul 2009 11:39:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/Ai9Fhw2nAl0UqC4loY1WPZ6+qtqd59Gil4+sL12 K67nFSSJHrl04I User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <871vobkny7.fsf@catnip.gol.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:112895 Archived-At: > Why do you keep talking about "tear-off windows"? They aren't the focus > of this discussion. This subthread was triggered by the framelet proposal which introduced tear-off windows together with separate tool/menu/tabbars. The idea or introducing such features was the premise for my initial posting which you tend to ignore all the time. I said that if we want these sort of things then we should use frames instead of windows. I never proposed to use frames unconditionally (which would be ridiculous BTW since I already spent quite some time modifying the window code). But I have to consider the possibility that users regard issues like tear-off windows and separate tool/menu/tabbars important enough so I have to make sure which way to go. > 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. But precisely that is the problem: If a user is allowed to escape the automatic layout (any maybe return to it at some later moment) we have to handle that. It's already hard enough to handle the case where a user invokes `display-buffer' within the automatic layout in order to show a help or info window and later quit that window. IIRC ECB saves the current window layout for that purpose leaving a one window frame, splits that window, makes one window the help/info window and fills the other window with the saved layout. Now how to you suppose us to handle the case where we have to fill the space left by a torn-off window and reintegrate that window in the automatic layout? >> 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.] Yes, and I conjectured that setting up such a mechanism is quite as complicated as setting up an mechanism for automatic layout of windows within an Emacs frame. And I did this in a reply to Tom's earlier statement, namely > One large difference, though, is that framelets really require > more changes to the C code of Emacs while window groups can > get away with little or 0 changes to the C code. From some of the > conversation, I suspect that this is one of the big reasons that > there is support for window groups. to state that IMHO implementing window groups means to make considerably more changes to the C code than implementing framelets. >> 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. Emacs has overlays which can have a window property which can have the display engine handle the overlay differently when the property matches the window the overlay is displayed on. When you tear off a window the identity of that window changes and you have to check all overlays in all buffers whether any window property should get updated accordingly. > 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. ... or separate tool/menu/tabbars (unless the latter show up in the header lines). martin