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: read syntax for window configs Date: Sat, 6 Mar 2010 11:32:26 -0800 Message-ID: <8FE0E48DBF9E4A618C50413475DD174F@us.oracle.com> References: <86bpf7q3fc.wl%lluis@ginnungagap.pc.ac.upc.edu><87wrxvyijr.fsf@stupidchicken.com><4B8C42E2.3080308@siege-engine.com><7697A57B1AD9104F993CDF6A5B69430C09227D1F24@CORPMAIL08.corp.capgemini.com><878wabxg0x.fsf@uwakimon.sk.tsukuba.ac.jp><87mxyrhxq8.fsf@lola.goethe.zz><7697A57B1AD9104F993CDF6A5B69430C09227D1FCE@CORPMAIL08.corp.capgemini.com><7697A57B1AD9104F993CDF6A5B69430C09227D1FF5@CORPMAIL08.corp.capgemini.com><87wrxu79r6.fsf@mail.jurta.org><87wrxuw0pd.fsf@uwakimon.sk.tsukuba.ac.jp><86716EEF25B64190B631AD85710E965D@us.oracle.com> <87bpf1a4l5.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 1267912528 20640 80.91.229.12 (6 Mar 2010 21:55:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Mar 2010 21:55:28 +0000 (UTC) Cc: klaus.berndl@capgemini-sdm.com, sperber@deinprogramm.de, lennart.borgman@gmail.com, emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 06 22:55:22 2010 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 1No1Z0-0005BF-FM for ged-emacs-devel@m.gmane.org; Sat, 06 Mar 2010 22:29:34 +0100 Original-Received: from localhost ([127.0.0.1]:51699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nnzkh-0003ud-Jj for ged-emacs-devel@m.gmane.org; Sat, 06 Mar 2010 14:33:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nnzk6-0003ix-H9 for emacs-devel@gnu.org; Sat, 06 Mar 2010 14:32:54 -0500 Original-Received: from [140.186.70.92] (port=57601 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nnzk5-0003iL-G8 for emacs-devel@gnu.org; Sat, 06 Mar 2010 14:32:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nnzk4-0005DG-0z for emacs-devel@gnu.org; Sat, 06 Mar 2010 14:32:53 -0500 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:55051) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nnzk3-0005Cr-S4 for emacs-devel@gnu.org; Sat, 06 Mar 2010 14:32:51 -0500 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o26JWcAD021669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Mar 2010 19:32:39 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o26JWaDa014111; Sat, 6 Mar 2010 19:32:37 GMT Original-Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 63908841267903942; Sat, 06 Mar 2010 11:32:22 -0800 Original-Received: from dradamslap1 (/141.144.160.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Mar 2010 11:32:22 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87bpf1a4l5.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acq9WVNBaW8J0FDHQr+3KhN9Kd3PmQABDjJg X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4B92ADD6.00B5:SCFMA4539814,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:121697 > > Read syntax for window (and frame) configs would be very welcome. > > > > Currently, we have things like desktop.el that save some > > session state, but they don't save window/frame configs. > > There is a task in etc/TODO: > > ** Make desktop.el save the "frame configuration" of Emacs (in some > useful sense). Better to separate that feature out. Have a separate feature (library) to save window/frame configs. And then let desktop.el optionally make use of that separate feature. IOW, saving/restoring buffers, variables, etc. (what desktop does today) is different from saving/restoring window/frame configs. There is no reason to couple them by putting them in the same library - no reason to require code that needs only one of the features to load a big library that does both. > > FWIW, one of my libraries bookmarks desktops, so you can > > more easily switch among different contexts (desktop files). > > This looks like another task in etc/TODO: > > ** Give desktop.el a feature to switch between different named > desktops. Desktop has an unfortunate limitation (IMO) that is also, it seems, somewhat gratuitous: It expects (and therefore pretty much requires) only one desktop file per directory. All of the desktop.el functions are written that way - they drive off of a directory name. That means that trying to use the desktop.el code to do something more flexible, switching among arbitrary desktop files located anywhere, is ugly. My code has to jump through some otherwise unnecessary hoops to do this. I had to duplicate and modify some of the desktop.el code, just to get around this function interface. Anyway, the TODO item you cite is fine, but a welcome preliminary TODO item would be to change the desktop.el functions to accept (at least optionally) a desktop file location (file name), and not just rely on a directory. See also thread "desktop.el - only one desktop file per directory?", http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01112.html --- FWIW, my bookmark code is a trivial extension to bookmark.el, which defines a `desktop' bookmark type. I just define: 1. A command to set a desktop bookmark (reads a file name and writes a desktop file). 2. A function to make a desktop bookmark record ( records the desktop file and a desktop bookmark handler). 3. A desktop bookmark handler (gets the desktop file name from the bookmark and changes to that saved desktop). The code is here: http://www.emacswiki.org/emacs/bookmark%2b.el Because I allow multiple desktop files per dir, the code for #1 and #3 is more involved that it should need to be. With more reasonable desktop.el functions, which accepted a desktop file name, it would be short and simple. Note: My code doesn't worry about multiple users and sessions wrt locks - it is rudimentary (hence fragile) wrt locking. While I allow multiple desktop files per dir, I haven't bothered to try to handle multiple lock files per dir etc. Really, it is an individual desktop file (not a directory) that should have an associated lock. Truly breaking with the current directory-level granularity would require handling locks on a per-file basis, I imagine (but I'm no expert on how the locking works). If the TODO item I proposed were implemented, then the necessary file-level locking would hopefully be taken care of also.