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 19:25:06 +0200 Message-ID: <4A65F9F2.3060908@gmx.at> References: <20090712180623.GA1009@muc.de> <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> <4A658CD2.8020504@gmx.at> <4A65C1FF.50602@gmx.at> 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 1248197134 14578 80.91.229.12 (21 Jul 2009 17:25:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jul 2009 17:25: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, acm@muc.de, drew.adams@oracle.com, Miles Bader To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 21 19:25: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 1MTJ5g-0002Wa-S4 for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 19:25:25 +0200 Original-Received: from localhost ([127.0.0.1]:44343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTJ5f-00084v-Ho for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 13:25:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTJ5b-00084T-0z for emacs-devel@gnu.org; Tue, 21 Jul 2009 13:25:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTJ5V-00083V-Nv for emacs-devel@gnu.org; Tue, 21 Jul 2009 13:25:17 -0400 Original-Received: from [199.232.76.173] (port=59211 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTJ5V-000833-Fm for emacs-devel@gnu.org; Tue, 21 Jul 2009 13:25:13 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:35913) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MTJ5U-0007Yo-SM for emacs-devel@gnu.org; Tue, 21 Jul 2009 13:25:13 -0400 Original-Received: (qmail invoked by alias); 21 Jul 2009 17:25:11 -0000 Original-Received: from 62-47-56-251.adsl.highway.telekom.at (EHLO [62.47.56.251]) [62.47.56.251] by mail.gmx.net (mp065) with SMTP; 21 Jul 2009 19:25:11 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19KcuE5gkdKsk7oIHcjEJmxXE7wGjhWS1IvH2ayem 7oBex0BZpDOYu8 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 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:112932 Archived-At: > I agree with Miles here: it's a non-starter. If you want other reasons > for it, think about the difficulties we face already with timing issues > in requests for resizing/moving frames and/or controlling focus of newly > created frames. We have lots and lots of bugs there, most of which are > a nightmare to fix because we're at the mercy of the WM. I agree with you and Miles that WM interaction is problematic. But if we don't use frames then IMHO framelets, tear-off windows and multiple tool and/or menubars are non-starters too. And here we apparently disagree. >> In three steps: (1) save a frame's window configuration, (2) tear off a >> window from that frame and re-purpose it into another frame, (3) restore >> the window configuration saved in step (1). Gets you two windows with >> the same identity. No fun here, no fun at all ... > > I think such window-configurations shouldn't save window identities. `current-window-configuration' combined with `set-window-configuration' does preserve window identities. > Especially if one wants to be able to restore one window-configuration in > a different frame (and/or save that config into a file). These would have to become different functions anyway and would always have to create a new window. > In other words, I think that the issue of window-identity w.r.t > window-configurations is one where there's no way to win. I think the > least breakage will happen when we give up on preserving those > identities. We currently do not have any problems with window identities. So why introduce problems by trying to preserve a window's identity when tearing it off? martin