From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#14964: 24.3.50; doc of `compare-window-configurations' Date: Sun, 28 Jul 2013 18:57:48 +0200 Message-ID: References: <51e98138-a20c-48ad-bea2-de67eb6b04b5@default> <51F3826F.9060600@gmx.at> <51F4D8FF.6000703@gmx.at> <25701584-34ff-4754-8d10-7f2d223205ac@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1375030754 4034 80.91.229.3 (28 Jul 2013 16:59:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jul 2013 16:59:14 +0000 (UTC) Cc: 14964@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 28 18:59:15 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V3UJO-0003Zu-Oz for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Jul 2013 18:59:15 +0200 Original-Received: from localhost ([::1]:52906 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3UJO-0001vX-E1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Jul 2013 12:59:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3UJH-0001tG-Bb for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2013 12:59:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3UJC-0007UD-TC for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2013 12:59:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3UJC-0007U9-OP for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2013 12:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V3UJC-0001qA-9H for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2013 12:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Jul 2013 16:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14964 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14964-submit@debbugs.gnu.org id=B14964.13750307187026 (code B ref 14964); Sun, 28 Jul 2013 16:59:02 +0000 Original-Received: (at 14964) by debbugs.gnu.org; 28 Jul 2013 16:58:38 +0000 Original-Received: from localhost ([127.0.0.1]:54621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3UIn-0001pC-GC for submit@debbugs.gnu.org; Sun, 28 Jul 2013 12:58:37 -0400 Original-Received: from mail-ea0-f180.google.com ([209.85.215.180]:48621) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3UIk-0001oo-NA for 14964@debbugs.gnu.org; Sun, 28 Jul 2013 12:58:35 -0400 Original-Received: by mail-ea0-f180.google.com with SMTP id r16so2495084ead.39 for <14964@debbugs.gnu.org>; Sun, 28 Jul 2013 09:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mLavCS10o6oqmCfSzIKh1dzSDmsYD+nDF4rP+q+sPCQ=; b=yZReKk/hKtl/pj9VxPci6bmmtQiFbMQl8C3FHPNwSOD2zXTyyT8ziYPrWdmC3wljPb oTn8OfWHhrLNHQpGzC1EnnLuvE2KLBffnUiC2evDeEsE6XfEQ4thav0MGOMt9rBm/6ha UJMLq85rgABvljsCZZX2diXBGO/j5wlEO+CI1B0MmMCk3/XbHMKBpil9EzRwHolM0irn B7utmcikvY53ZS6NUIhwCrb50EO8HnbHgdaOmCEcl45tslm1dQoc3YvFF9gtfIXQ0rWD QIjrVS5VYoLrYjFc+8pc1teyYJ2mMPsBR5LlUjXXu2gaBYRsCwFl+O1GR86SLE/ohgTq U9Mw== X-Received: by 10.14.218.8 with SMTP id j8mr55997050eep.129.1375030708748; Sun, 28 Jul 2013 09:58:28 -0700 (PDT) Original-Received: by 10.15.23.70 with HTTP; Sun, 28 Jul 2013 09:57:48 -0700 (PDT) In-Reply-To: <25701584-34ff-4754-8d10-7f2d223205ac@default> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76734 Archived-At: On Sun, Jul 28, 2013 at 4:49 PM, Drew Adams wrote: > Yes, I am hoping exactly that. His work with desktop.el will apparently use > Lisp-readable representations of sets of frames. I hope this will be > applied/extended to the frame-configuration functions, so we can optionally > get Lisp-readable frame configurations (with the same properties and > interfaces as we have now). I think frame configurations are a bit underdocumented. Also, I'm not sure what do they record and how that differs of what I've had to implement for desktop.el (other than the fact that with frame configurations you cannot restore a deleted frame, and you can with desktop frame-states). In particular, according to current-frame-configuration's docstring: Its car is `frame-configuration'. Each element of the cdr is a list of the form (FRAME ALIST WINDOW-CONFIG), where FRAME is a frame object, ALIST is an association list specifying some of FRAME's parameters, and WINDOW-CONFIG is a window configuration object for FRAME." - FRAME, as a frame object, can not be serialized to disk. Serializing it means serializing its contents and attributes, as I try to do in desktop.el. - ALIST specifies "some of FRAME's parameters", but it doesn't say which ones, or the criteria used to select them, or why these parameters are important and not others. - WINDOW-CONFIG is also not serializable, but Martin's window-state-(get|put) does something similar. So, what do you expect of "Lisp-readable frame configurations"? A Lisp readable frame configuration is not very different of a desktop frame-state, and any function that serializes it will necessarily do something similar to desktop-save-frames (details of output format can vary, of course). Which differences are you're interested in? (Other than the currrent API of desktop-save-frames being currently not very reuse-friendly, I mean.) IIUC, what you would do is, either add parameters to the current frame-configuration functions to obtain a serializable config, or add a serialize-frame-config function. Isn't that more or less what I've been doing? If there is information that frame-configuration saves and desktop-save-frames does not, and is information that can be meaningfully restored in another Emacs session, we can discuss adding it. > E.g., a frame config would continue to look like this, even when > Lisp-readable: > > (frame-configuration FRAME+WINDOW-CONFIG...) > > where FRAME+WINDOW-CONFIG would be a Lisp-readable representation of a frame > (a set of frame parameters, preferably at least the same ones recorded now) > plus the frame's window configuration. I see your little trick here ;-) A frame configuration is not the configuration of a frame, but of all existing frames. So a serialized frame configuration would be (frame-configuration (FRAME+WINDOW-CONFIG)...) and that's just syntactic sugar over what a desktop frame-state currently is: ((FRAME-PARAMS . WINDOW-STATE)...) > Let me know if you (e.g. Juanma) prefer that I file this as a separate > bug (enhancement request). If so, I will, repeating what I've said here. No, I just want to understand what is being requested. In other words, the API that does not exist currently and you'd like to see. > a. these structures documented, i.e., the structure advertised as such, or > b. access functions defined for their parts. I'd like to see that, too. > IOW, either an open, advertised structure or a black box but providing > advertised ways to get at the various components. As previously discussed, in private and in my last emacs-devel message, I'm open to that but I don't think that providing an API to serialize individual frames makes much sense. But ways to make desktop-save-frames more open and accesible? Definitely I'm in. J