From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Window configurations Date: Sun, 2 May 2010 16:34:06 -0700 Message-ID: References: <4BB4CF6B.2000007@alice.it> <87eii63v4j.fsf@mail.jurta.org><0840B3F4D9E84706874EDD2CA2CC4236@us.oracle.com><87vdbhgqgd.fsf@mail.jurta.org><828BB36311A84C43B96D1F2A559DACAE@us.oracle.com><87d3xo662u.fsf@mail.jurta.org><69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com><87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at><87zl0rtmqy.fsf@mail.jurta.org> <878w822i5a.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1272843381 32586 80.91.229.12 (2 May 2010 23:36:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 2 May 2010 23:36:21 +0000 (UTC) Cc: 'Ken Hori' , 'martin rudalics' , 'Emacs' To: "'Juri Linkov'" , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 03 01:36:17 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1O8ihs-0004Z0-8u for ged-emacs-devel@m.gmane.org; Mon, 03 May 2010 01:36:16 +0200 Original-Received: from localhost ([127.0.0.1]:57726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8ihr-0002dV-LA for ged-emacs-devel@m.gmane.org; Sun, 02 May 2010 19:36:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O8ihm-0002dO-Qs for emacs-devel@gnu.org; Sun, 02 May 2010 19:36:10 -0400 Original-Received: from [140.186.70.92] (port=57699 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8ihk-0002dG-O1 for emacs-devel@gnu.org; Sun, 02 May 2010 19:36:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O8ihi-0006Og-Mv for emacs-devel@gnu.org; Sun, 02 May 2010 19:36:08 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:21727) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O8ihi-0006OD-I4 for emacs-devel@gnu.org; Sun, 02 May 2010 19:36:06 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o42NZjUc020305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 May 2010 23:35:46 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o42MYm4R009177; Sun, 2 May 2010 23:35:43 GMT Original-Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 208217821272843233; Sun, 02 May 2010 16:33:53 -0700 Original-Received: from dradamslap1 (/141.144.160.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 02 May 2010 16:33:53 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <878w822i5a.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcrqN2V4LkqBcYiMTa2bw3ulVP26IwAAFkAA X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090202.4BDE0C53.0016:SCFMA922111,ss=1,fgs=0 X-detected-operating-system: by eggs.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:124447 Archived-At: > >> Could we add as an extra `buffer-file-name' alist element > >> in the sexp of a window-configuration or is that a bad idea? > >> (I was just tring to reconstruct a window-configuration > >> after an emacs reboot but quickly found out filenames > >> weren't just there.) > > > > For saving/restoring, we'll probably need to save the same info used > > by bookmark.el or desktop.el (unifying the two might also be a good > > idea, BTW). > > Since bookmark.el is conceptually more low-level than desktop.el, > the latter could use a subset of services provided by bookmarks. > > There is one problem of using bookmark records for desktop.el. > Some bookmarks take too much time to restore when reading > from the desktop file. So packages will need to distinguish > between making a bookmark for bookmark.el or desktop.el to not > save some bookmarks in the desktop file. Maybe > `bookmark-make-record-function' will require a new argument for that. Sigh. I really wish you guys wouldn't mess with this. Put what you want in a window config, but please do not try "unifying" bookmarks and desktops (and window configs). If anything, bookmarks are more general and higher-level (not lower-level) than desktops. Why? Because you can save/restore many different types of things as bookmarks, each in its own way. Each can have its own handler. Anything can be bookmarked. A desktop records one type of thing: a desktop, no matter what you might want to stuff into a desktop, no matter how complex it is. If you want to add handlers or other bells and whistles to desktops, go for it, but please do not try to merge bookmarks and desktops as if they were the same thing or one were an instance or a subset of the other. They both record state persistently and restore it; that's all. There is no reason to confuse the concepts or merge the code. On the other hand, a desktop can be targeted as one kind of bookmark - a bookmark can restore a desktop just as it can restore an Info node. That is the case in bookmark+.el, for example. But it does not make sense to record all of the info for a desktop directly in the bookmark (and thus in a bookmark file, which can contain _lots_ of bookmarks). What makes sense is for a desktop bookmark to simply refer to a particular desktop file, which records the desktop info. Likewise, for a window-config bookmark. (I'm still hoping you will not hard-couple window-configs and desktops - each can be used independently of the other, as well as together.) Nor does it make much sense to add bookmark records to a desktop file. I don't know what kind of bookmark "info" or bookmark "services" you think would be required by desktops. Do you plan on adding handlers to desktops? Whatever. Add whatever you must to window-config records or desktop records, but please keep bookmarks separate from them both. Keep things simple and separate, so users and programmers can easily combine them at will in various ways. Just give us a way to save and restore window configs, and we can always combine that (or not) with saving and restoring desktops. And we can always create a bookmark to either. Please do not start "unifying" everything into one big ball of knots. Wrt generalizing and improving _bookmarking_, which is a different topic from making window configs persistent and restorable, see bookmark+.el. All of that improvement could be added to Emacs, as a patch to bookmark.el. (No, I don't want to argue about it. If you don't want it, that's fine.) http://www.emacswiki.org/emacs/BookmarkPlus Bookmarking is about saving and restoring something - anything. It is therefore about handling different kinds of stateful things differently. To improve bookmarking, work on making it easy for users to distinguish and access the various types, provide type-specific UI features and help, and so on. Forget about constructing the uber unifying bookmark-cum-desktop-cum-window-config cathedral. Please. The goal should be separate Lego blocks of different shapes that fit together, not a big wad of fused plastic.