From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Wed, 22 Jul 2009 03:38:57 +0300 Organization: JURTA Message-ID: <8763dlmr82.fsf@mail.jurta.org> References: <20090712180623.GA1009@muc.de> <87k52dycha.fsf@stupidchicken.com> <4A5C2C96.4080802@swipnet.se> <43507.130.55.118.19.1247580320.squirrel@webmail.lanl.gov> <20090714151327.GA1718@muc.de> <53864.130.55.118.19.1247586358.squirrel@webmail.lanl.gov> <87r5whgzvg.fsf@mail.jurta.org> <0C244EB2B99349238E281268B0339C72@us.oracle.com> <20090716200959.GA4298@muc.de> <87vdlstkg4.fsf@mail.jurta.org> <87skgwb9na.fsf@stupidchicken.com> <87ab34ti2o.fsf@mail.jurta.org> <4A61D2A5.8080504@gmx.at> <87vdlpfun0.fsf@mail.jurta.org> <4A62F79A.90001@gmx.at> <873a8s5wwm.fsf@mail.jurta.org> <4A6439FE.8000204@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248227252 8626 80.91.229.12 (22 Jul 2009 01:47:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2009 01:47:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 22 03:47: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 1MTQvU-0003VH-A8 for ged-emacs-devel@m.gmane.org; Wed, 22 Jul 2009 03:47:24 +0200 Original-Received: from localhost ([127.0.0.1]:48168 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTQvT-0000UC-LA for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 21:47:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTQt7-0007Ac-Id for emacs-devel@gnu.org; Tue, 21 Jul 2009 21:44:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTQt2-00078Q-9L for emacs-devel@gnu.org; Tue, 21 Jul 2009 21:44:57 -0400 Original-Received: from [199.232.76.173] (port=37960 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTQt2-00078I-38 for emacs-devel@gnu.org; Tue, 21 Jul 2009 21:44:52 -0400 Original-Received: from smtp-out2.starman.ee ([85.253.0.4]:42445 helo=mx2.starman.ee) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTQt1-0007uZ-I1 for emacs-devel@gnu.org; Tue, 21 Jul 2009 21:44:51 -0400 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Original-Received: from mail.starman.ee (82.131.55.232.cable.starman.ee [82.131.55.232]) by mx2.starman.ee (Postfix) with ESMTP id 306E93F40CF; Wed, 22 Jul 2009 04:44:44 +0300 (EEST) In-Reply-To: <4A6439FE.8000204@gmx.at> (martin rudalics's message of "Mon, 20 Jul 2009 11:33:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:112973 Archived-At: >> Yes, I meant to save window configurations across sessions in >> ~/.emacs.desktop. There are corresponding tasks in etc/TODO: >> >> ** Make desktop.el save the "frame configuration" of Emacs (in some >> useful sense). > > Did anyone ever specify what the "useful sense" of saving a frame > configuration is? I guess "useful" means an ability to restore a frame configuration to the state that was before saving. >> ** Give desktop.el a feature to switch between different named >> desktops. > > I don't use desktop so I suppose this means to let the user choose (at > the beginning of a session) among different saved desktops. Does > this have any peculiar relevance for window configurations (as soon as > it has been resolved in a more general sense)? I misread this task as "a feature to switch between different named frame configurations" that makes sense for the current discussion. >> ECB layout definitions are powerful but rely on `defadvice' and >> IMO they are over-complicated. > > Removing the defadvice dependency is a goal of the window groups > concepts. In what sense are ECB layouts over-complicated? ECB layouts are too specific to the code browser and can't be used stand-alone that would be a useful feature. But there are many good ideas in ECB. It uses procedural definitions for layouts like: (ecb-layout-define "left1" left (ecb-set-directories-buffer) (ecb-split-ver 0.3) (ecb-set-sources-buffer) (ecb-split-ver 0.5) (ecb-set-methods-buffer) (select-window (previous-window)) (ecb-split-hor 0.5) (ecb-set-history-buffer) (select-window (next-window (next-window)))) Such procedural definitions insure that created and restored window trees will be the same. Maybe desktop.el should try saving window trees with similar procedural structures where content of each restored window will be filled with either a file or the result of `desktop-buffer-mode-handlers'. I mean replacing `ecb-set-directories-buffer', `ecb-set-sources-buffer', `ecb-set-methods-buffer' in the example above with a single call to `desktop-create-buffer'. -- Juri Linkov http://www.jurta.org/emacs/