From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Fri, 17 Jul 2009 02:30:12 +0200 Message-ID: References: <20090712180623.GA1009@muc.de> <20090716200959.GA4298@muc.de> <87vdlstkg4.fsf@mail.jurta.org> <87skgwb9na.fsf@stupidchicken.com> <1247784574.6302.83.camel@dell-desktop.example.com> <1247787842.6302.90.camel@dell-desktop.example.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1247790636 21965 80.91.229.12 (17 Jul 2009 00:30:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jul 2009 00:30:36 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org, Juri Linkov , Stefan Monnier , Alan Mackenzie , Drew Adams To: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 17 02:30:28 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 1MRbLI-0007ND-2u for ged-emacs-devel@m.gmane.org; Fri, 17 Jul 2009 02:30:28 +0200 Original-Received: from localhost ([127.0.0.1]:35733 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRbLH-0008RM-CX for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2009 20:30:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRbLC-0008Or-Fg for emacs-devel@gnu.org; Thu, 16 Jul 2009 20:30:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRbL7-0008C4-OE for emacs-devel@gnu.org; Thu, 16 Jul 2009 20:30:21 -0400 Original-Received: from [199.232.76.173] (port=33745 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRbL7-0008Bb-JY for emacs-devel@gnu.org; Thu, 16 Jul 2009 20:30:17 -0400 Original-Received: from mail-bw0-f219.google.com ([209.85.218.219]:42829) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MRbL7-0002XU-8d for emacs-devel@gnu.org; Thu, 16 Jul 2009 20:30:17 -0400 Original-Received: by bwz19 with SMTP id 19so520022bwz.42 for ; Thu, 16 Jul 2009 17:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3+0mZvyQ2bqy7dhJnULkhWsVs8wJzMO4laSL6aOFFhg=; b=PbVi9bKWq1fOeF4KU1ktS1G6SAAbMRVgKLHyW+xNNVafxXQGMZx8Iu62D3C9/4TKt+ ERPxqoDV47wvGl2hiiVRQyJoOQbUTeNUxXEyN7bDLgraBSFA5CJkRa9yxDchS8nx8Sbw cydu5e4g+B0Q4LmR0wkFAX02F3421k/iKhD6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Bfn1qH3Rv3lMvGPh6Ye8BQS+KWouJYR4QNZqmE2lACnGtzJtGMj8iKyGtGseJvPCMQ HEz2d0CibARHy2vP9s52d9e7n7qFX5zvL9Vv5C/LYiPOPfDpfdMhj0nu20Z6y71AQMHX WUzexyhtZjuA74MjfUFN1Gmy43hsuk9Qc7BdI= Original-Received: by 10.223.113.68 with SMTP id z4mr70977fap.72.1247790613010; Thu, 16 Jul 2009 17:30:13 -0700 (PDT) In-Reply-To: <1247787842.6302.90.camel@dell-desktop.example.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:112584 Archived-At: On Fri, Jul 17, 2009 at 1:44 AM, Thomas Lord wrote: > On Fri, 2009-07-17 at 00:54 +0200, Lennart Borgman wrote: > >> I am unable to understand the "four framelettes". Why not just let any >> window be a framelette if desired? > > > I can't imagine a clean way for that to work > for two reasons. =C2=A0 First, it would allow unbounded > nesting of framelettes. Why is that a problem? > Second, I don't know about > you but I can't think of any semantics for window > configurations that would make that work nicely. I am not sure I understand. I just think of it as you described it (on a general level). - Inside a framelett window commands just affects that framelet. - A framelet inside a framelet is just treated as any other window if you are outside of it. - A framelet or a single window can be marked as "protected", but that holds just when you are doing operations from windows inside the same level. (Inside they do not touch them by definitions above and outside they are just seen as windows on the same level which may be protected or not.) > That being said, I'll observe that "any window a > framelette" is easily construed as a generalization > of "four fixed framelettes in the customary toolbar > and panel positions" and so it is not so absurd to think > of starting with the conceptually simpler "four framelettes" > idea and generalizing later if clear answers appear > for unbounded nesting and window configuration semantics. I do not understand why you think this is conceptually easier to restrict it to four framelettes and just one sublevel. Why is it easier? (I guess the code would have to handle that restriction and it just seems more complicated to me.)