From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#14964: 24.3.50; doc of `compare-window-configurations' Date: Mon, 29 Jul 2013 16:53:52 -0700 (PDT) Message-ID: <8c5571e7-7ce2-4581-a2e6-8026ddcd0e3c@default> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1375142128 16805 80.91.229.3 (29 Jul 2013 23:55:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Jul 2013 23:55:28 +0000 (UTC) Cc: Juanma Barranquero , 14964@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 30 01:55:25 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 1V3xHg-0000ub-FG for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Jul 2013 01:55:24 +0200 Original-Received: from localhost ([::1]:41885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3xHf-0005Ye-K3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jul 2013 19:55:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3xHU-0005VI-FI for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 19:55:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3xHL-0008Ej-4D for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 19:55:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3xHL-0008Dg-1B for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 19:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V3xHJ-0007w7-RK for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2013 19:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Jul 2013 23:55:01 +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.137514204730363 (code B ref 14964); Mon, 29 Jul 2013 23:55:01 +0000 Original-Received: (at 14964) by debbugs.gnu.org; 29 Jul 2013 23:54:07 +0000 Original-Received: from localhost ([127.0.0.1]:56956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3xGQ-0007te-OX for submit@debbugs.gnu.org; Mon, 29 Jul 2013 19:54:07 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:44777) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V3xGO-0007t4-G5 for 14964@debbugs.gnu.org; Mon, 29 Jul 2013 19:54:05 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6TNrspP011939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Jul 2013 23:53:56 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6TNrqfS016957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 23:53:53 GMT Original-Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6TNrq4c007112; Mon, 29 Jul 2013 23:53:52 GMT In-Reply-To: <51F61FF5.30500@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:76781 Archived-At: > > E.g. (current-frame-configuration t) would return a writable & readabl= e > > frame configuration. >=20 > With configurations you store and restore window positions and sizes in > situ. That is, you overwrite (in C) the members of the window structure > and rely on the fact that a configuration is an immutable memory object > to obtain correct bahavior. A function like `set-window-configuration' > does not check whether the object it restores is correct in some sense > or has been manipulated after it has been stored. It relies on your > hardware to do that. `window-state-put' OTOH is pretty failsafe in this > regard because it restores windows via the Lisp split and resize > operations. >=20 > > But the point is to have a standard structure that code can use and > > manipulate. >=20 > That would be clearly fatal as explained above. Changing anything in a > frame configuration is strictly forbidden. Is there some internal use of Emacs window and frame configurations? If not, i.e., if the only use is by users and Lisp code, using the available commands and other functions, then is there some reason that window and frame configurations should not enjoy the properties you mention that are missing and that are available with `window-state-*'? If not, then can we please unite the two, adding the benefits that you added for `window-state-*' to the others as well? The frame and window configurations that users and Lisp code can obtain from Emacs are at least recognizable as such (via predicates), and their parts are accessible (well, only the frame of a window config is accessible= , not any of its other parts, but all parts of a frame config are accessible, AFAICT). The data structure returned by `window-state-get' is not recognizable as such. There is not even a `window-state-p' predicate, let alone documented components. This is the only documentation I have seen - a comment in `window-state-get': ;; The return value is a cons whose car specifies some constraints on ;; the size of WINDOW. The cdr lists the states of the child windows ;; of WINDOW. And there is no documentation of either the car (what constraints? in what form?) or the cdr (what form? what order (if important)?)), beyond that. A proper, documented structure (whether list or defstruct) is what I would like to see instead. And unless there are really some good reasons not to, I would like to see the same structure used by the window-configuration functions (`current-window-configuration', `set-window-configuration', `window-configuration-p', `window-configuration-to-register'). IOW, you say that the window states you use and the window-configuration info are different. OK. How about unifying them? And doing so in such a way that the result presents the advantages of each, as far as possible? The advantages I see for a window or frame configuration are (a) recognizability (a type predicate) and (b) accessibility of its components. (Again, window configurations are inadequate wrt (b), but frame configs provide a reasonable model.) --- 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), and if possible unify it with the existing frame-configuration functions (`current-frame-configuration', `set-frame-configuration', `frame-configuration-p', `frame-configuration-to-register'). Let's not just come up with something new and superior and not leverage it for the existing functions. Use the new code for both, for example, after adding any advantages that the old code might provide and the new does not (e.g., a way of identifying the thing as a frame configuration). I'm sure you can argue that the things are not the same, and perhaps even give a reason why they should not be or cannot be the same. 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). Of course, parts that might not apply to one or the other use would be skipped over if just irrelevant in some context. 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. Fine. Then either some of that additional info might also be useful for a frame configuration, or none of it would. In either case, any such info that would not be useful for a frame config would be left out of it. 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. IOW, we can try to unify the two representations of a set of saved frames (or however you would like to characterize it), but that does not mean that the unified result needs to force either Desktop or the existing frame-config functions into a straitjacket.