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: Tue, 30 Jul 2013 02:18:59 +0200 Message-ID: References: <51e98138-a20c-48ad-bea2-de67eb6b04b5@default> <51F3826F.9060600@gmx.at> <51F4D8FF.6000703@gmx.at> <25701584-34ff-4754-8d10-7f2d223205ac@default> <51F61FF5.30500@gmx.at> <8c5571e7-7ce2-4581-a2e6-8026ddcd0e3c@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1375143615 30835 80.91.229.3 (30 Jul 2013 00:20:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2013 00:20:15 +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 Tue Jul 30 02:20: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 1V3xfj-0004e8-0w for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Jul 2013 02:20:15 +0200 Original-Received: from localhost ([::1]:47586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3xfi-0003gm-JG for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jul 2013 20:20:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3xfc-0003fE-EH for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 20:20:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3xfX-0008It-VP for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 20:20:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3xfX-0008GS-SZ for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 20:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V3xfW-0000eZ-LX for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 20:20: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: Tue, 30 Jul 2013 00:20: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.13751435882468 (code B ref 14964); Tue, 30 Jul 2013 00:20:02 +0000 Original-Received: (at 14964) by debbugs.gnu.org; 30 Jul 2013 00:19:48 +0000 Original-Received: from localhost ([127.0.0.1]:57018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3xfH-0000dj-Pz for submit@debbugs.gnu.org; Mon, 29 Jul 2013 20:19:48 -0400 Original-Received: from mail-ee0-f42.google.com ([74.125.83.42]:53509) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3xfF-0000dL-6c for 14964@debbugs.gnu.org; Mon, 29 Jul 2013 20:19:46 -0400 Original-Received: by mail-ee0-f42.google.com with SMTP id b45so418324eek.29 for <14964@debbugs.gnu.org>; Mon, 29 Jul 2013 17:19:39 -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=7p0zV9rLvWsbkVlWW3sDmLuM6RP9XbKyWyCktvqAYNc=; b=XtequfDTkDhh0kk52norC2ZR3qrwxWGT3JggBsCCGqlyUTw2BLUyoB1v7bvN4qtF9V CQvOMg3YWyYjVU72VcsePPos17ZaJ9PDkfEsadXFQp6dm3wwH1euUjT5VlZXS5dhBFWE P0s465ez2VcYkDiDExGn/zEnrnJGnO7CWwMdH1xHPB4nKXj8ugSmRCAAzspBG31rQghI tw5eu3AqGia9KStI9bIPtuWpVZrVRoboRF/+EWTcWsQQ9vt6RgfcIdx+3dx98+26U2gq 5jx0UbJQO3+M67wKJ8Xs6OgAXPg9EGluk6D6bzglCUSqBBtLI73l/iTOc+d1TqzYcH5D x6IA== X-Received: by 10.15.76.71 with SMTP id m47mr61024736eey.70.1375143579285; Mon, 29 Jul 2013 17:19:39 -0700 (PDT) Original-Received: by 10.15.23.70 with HTTP; Mon, 29 Jul 2013 17:18:59 -0700 (PDT) In-Reply-To: <8c5571e7-7ce2-4581-a2e6-8026ddcd0e3c@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:76783 Archived-At: On Tue, Jul 30, 2013 at 1:53 AM, Drew Adams wrote: > I make the same argument/request wrt frame configurations and the new > Lisp-readable frame-state information that Juanma is developing. Please > give us a recognizable frame-configuration object (by whatever name), I'm currently separating the frame-state code into a new package (surprisingly named frame-state.el) which does not depend on desktop.el at all. desktop.el will be a client of it (the main client, I'd say). One of the goals is to make frame-state a bit less dependent on global state, though removing all such is impractical. The new format for frame states is (frame-state PROPLIST (FRAME-STATE WINDOW-STATE)...) where `frame-state' is a symbol, and PROPLIST is a property list. The only defined keyword is :version, which will be 1 and would be increased if the format were modified. Additional properties can be added by the user when creating a frame-state. Two that spring to mind would be :name (a readable name) and :id (a md5 or random key or whatever to simplify comparing two frame-states). FRAME-STATE and WINDOW-STATE are as now: a frame parameter list and the output of window-state-get. > if possible unify it with the existing frame-configuration functions > (`current-frame-configuration', `set-frame-configuration', > `frame-configuration-p', `frame-configuration-to-register'). Not possible. current-frame-configuration has no arguments, just "freezes" the current frame configuration. frame-set-save has at least two arguments (a frame-list to limit the frames being considered, and a filter-alist which will default to frame-state-filter-alist (previously known as desktop-filter-frame-params-alist). I'm in the middle of coding this, so it is possible that I end adding more args. frame-state-restore has still more arguments, to select the restoring behavior that is currently set via desktop-* customizable options (desktop will keep these options, which will be the source of the args, though they don't have to be identical and the correspondence is not necessarily one-to-one; let's see). frame-state-p is trivial: (defun frame-state-p (frame-state) "If FRAME-STATE is a frame-state, return its :version. Else return nil." (and (eq (car-safe frame-state) 'frame-state) (plist-get (cl-second frame-state) :version))) and `frame-state-to-register' should be equally easy. > But please > think carefully about this and do not just dismiss it. That the two are > not yet the same is obvious. That users and Lisp code should not be able > to use the same thing for both is not yet clear (to me). It's not clear to me either, but I see enough differences to remain deeply unconvinced. > I get the impression from Juanma's mails that there is quite a bit more > that is saved with his frame-set saved state (for Desktop) than is included > in a frame configuration. He has explained that some info about relations > among the current frames is needed, for instance: it is not enough to just > save the parameters and root window state for each frame. I wouldn't say "quite a bit more". The minibuffer relationships, and also some frame state (position, size, fullscreen state, font, a few other parameters) which must be protected in case the user restores in a tty. > Desktop would continue to save that info, but it would be separate. > Desktop would save most of the frames info in the form of a frame config > and the rest of it separately. For example, there are perhaps some > frame-realated variables that are relevant when saving the state of all > the frames, and perhaps those are not pertinent for a frame config (just > guessing). Desktop would save those separately. At the moment, the readable frame-config format simply does not exist, so I'm not going to worry about being similar or different to it. Sorry. J