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: Gtk tabs in emacs, new branch Date: Sat, 24 Apr 2010 07:41:18 -0700 Message-ID: <828BB36311A84C43B96D1F2A559DACAE@us.oracle.com> References: <4BB4CF6B.2000007@alice.it> <4BB59476.7010600@swipnet.se><4BB5C01E.10701@alice.it> <4BB608EE.7080101@swipnet.se><4BB9A469.6050608@alice.it> <4BC072C3.2080302@swipnet.se><4BC0B692.2000702@alice.it> <4BC0BD6D.3060103@swipnet.se><4BC0F715.2060605@alice.it><45EB8DD4-B0F8-4FB3-941F-13FADA4DAD66@swipnet.se><4BC1854B.2060409@alice.it> <4BC1A9D2.8050607@swipnet.se><4BC206C0.2010202@alice.it> <87fx2pdvfq.fsf@mail.jurta.org><87y6gg95ad.fsf@mail.jurta.org><750140A47B7D4FBD93371813D65478F8@us.oracle.com><87eii63v4j.fsf@mail.jurta.org><0840B3F4D9E84706874EDD2CA2CC4236@us.oracle.com> <87vdbhgqgd.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 1272120140 25169 80.91.229.12 (24 Apr 2010 14:42:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Apr 2010 14:42:20 +0000 (UTC) Cc: 'Emacs' To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 24 16:42:19 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 1O5gYj-0008RJ-VG for ged-emacs-devel@m.gmane.org; Sat, 24 Apr 2010 16:42:18 +0200 Original-Received: from localhost ([127.0.0.1]:44780 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5gYj-0000wD-6R for ged-emacs-devel@m.gmane.org; Sat, 24 Apr 2010 10:42:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5gY9-0000m9-Gk for emacs-devel@gnu.org; Sat, 24 Apr 2010 10:41:41 -0400 Original-Received: from [140.186.70.92] (port=44619 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5gY7-0000kO-5T for emacs-devel@gnu.org; Sat, 24 Apr 2010 10:41:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5gY4-0007Td-OR for emacs-devel@gnu.org; Sat, 24 Apr 2010 10:41:38 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:43811) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5gY4-0007TS-F0 for emacs-devel@gnu.org; Sat, 24 Apr 2010 10:41:36 -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 o3OEfUAN021383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Apr 2010 14:41:32 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 o3OCLT1L009724; Sat, 24 Apr 2010 14:41:29 GMT Original-Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 186434781272120073; Sat, 24 Apr 2010 07:41:13 -0700 Original-Received: from dradamslap1 (/141.144.168.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 24 Apr 2010 07:41:13 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87vdbhgqgd.fsf@mail.jurta.org> Thread-Index: Acrjj5tepZysdwWpRKKf2WnbGqc7jAAIDNAw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090207.4BD3031D.0123: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:124170 Archived-At: > > Can users save such frame & window configs independently of > > desktops - and vice versa? Can they save individual > > frame/window configs as well as all configs > > together? > > If you want to save frame and window configurations > independently of desktops, you can easily do this using the > same functions that desktop.el now uses. So is that confirmation or not that one can save desktops without frame+win configs and one can also save frame configs or window configs or both independently of desktops (the traditional desktop info)? And can users do that interactively out of the box, or are you saying only that someone is free to create some user commands to do that using existing desktop functions? > > A desktop saves some variables, buffers, etc. Users should > > be able to save just frame/window state or just the > > vars+bufs state, as well as being able to save > > everything together at once. > > There is a new variable `desktop-save-frame-configuration' > that defines whether to save frame and window configurations > to the desktop. It is nil by default. You don't also say that there is a way to save frame and window configs without saving them to a desktop file. Or whether there is a way to save them without also saving the other desktop info (buffers, vars etc.). It sounds like frame+win are optionally part of a desktop, but not the contrary as well. That is different from them being separate things that can optionally be combined. I don't care much about the names - whether, for instance, "desktop" applies to what it means now (buffers, vars, etc.) or it is changed to apply to everything, including frames and windows. What I am concerned about is being able to easily save & restore the different kinds of things separately. > > Also, desktop.el has a big limitation (which I would like > > to see removed): it assumes only one desktop file per directory. > > It's a separate task to implement named desktops. > > I imagine that named desktops should be an object above frames > in the hierarchy of screen objects: > - desktop - frame - tab - window configuration - window > So switching desktops could be like switching frames: > M-x select-desktop-by-name RET > will read a desktop name, delete old frames by calling > `desktop-clear', and create a new desktop by calling > `desktop-read' with the selected name. I do not really want to see desktops and frames coupled that way. Again, the names don't matter to me much - what I want is to be able to save & restore such different things together or separately. I did not mention "named desktops". I asked to be able to have more than one desktop file per directory. Currently, the desktop functions assume you can have only one desktop file per dir. I would like the basic desktop functions to accept an optional FILE arg that tells them where the desktop file is. (If no such arg is passed, then they could do as they do now: look to `desktop-dirname' to find the file.) That would permit other code to pass a FILE arg to directly specify a desktop file to use. I have desktop bookmarks, for instance. Because the desktop.el code does not allow a caller to specify the file to use, my code jumps through a few extra hoops. Look at `desktop-change-dir' and `desktop-read'. They just change to the desktop represented by a particular desktop file. But they assume one file per dir, so they accept only a dir as arg. You would expect that you could explicitly pass a desktop file to read, but you cannot. The desktop.el code seems to be oriented toward a particular interaction between users and its basic features. That's the problem, as I see it. It has general features of saving and restoring a desktop to/from a file, but the functions that perform those basic operations are cobbled by making them assume a particular UI. That makes them less general (less useful) than they could be. IOW, there is not enough separation between the basic desktop functions and the UI that uses them - the UI design bleeds down into the basic functions themselves. We need not change the desktop UI. (But we could do that, to let users use multiple files per dir interactively as well.) The basic desktop functions could still assume that the desktop file they need is in the `desktop-dirname' dir by default. All I'm suggesting is that these functions should allow an optional parameter that provides the desktop file location. Other changes to the code (e.g. locking) might also be necessary to allow use of multiple files per dir - dunno. I'm guessing that the reason behind the original one-desktop-file-per-dir design had to do with locking (multiple users etc.). I don't know what all might be involved in trying to remove this limitation (maybe allow multiple lock files per dir?). For my use of desktop files for bookmarks, I want to let users save desktop files anywhere, and I don't use the locking. I brought up this point because you seem to be coupling persistence of frame and window configs with desktop files - and hence extending the limitation of one such file per dir to the new feature as well. That means users cannot have multiple frame-config files per dir etc. Don't get me wrong. I'm very glad you're working on this, and I don't pretend to be an expert on desktops or the desktop.el code. I just would like things to be modular - separable and combinable, and I would like the basic save-&-restore functions to handle multiple state-saving files per dir. > > Can users hook into this to handle user-defined frame > > parameters also? The feature should be open and not limited to > > a predefined set of parameters. > > Yes, there is a new variable `desktop-frame-parameters-to-save'. Very good.