From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#14964: 24.3.50; doc of `compare-window-configurations' Date: Tue, 30 Jul 2013 11:13:20 +0200 Message-ID: <51F783B0.2030303@gmx.at> 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; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1375175663 12712 80.91.229.3 (30 Jul 2013 09:14:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2013 09:14:23 +0000 (UTC) Cc: Juanma Barranquero , 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 11:14:22 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 1V460Z-0000wt-Mz for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Jul 2013 11:14:19 +0200 Original-Received: from localhost ([::1]:41699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V460Z-0004Rj-92 for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Jul 2013 05:14:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V460P-0004PY-Bs for bug-gnu-emacs@gnu.org; Tue, 30 Jul 2013 05:14:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V460I-0004yl-2R for bug-gnu-emacs@gnu.org; Tue, 30 Jul 2013 05:14:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V460H-0004yh-Uu for bug-gnu-emacs@gnu.org; Tue, 30 Jul 2013 05:14:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V460H-0000un-Nc for bug-gnu-emacs@gnu.org; Tue, 30 Jul 2013 05:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Jul 2013 09:14: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.13751756193425 (code B ref 14964); Tue, 30 Jul 2013 09:14:01 +0000 Original-Received: (at 14964) by debbugs.gnu.org; 30 Jul 2013 09:13:39 +0000 Original-Received: from localhost ([127.0.0.1]:57503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V45zu-0000t8-JU for submit@debbugs.gnu.org; Tue, 30 Jul 2013 05:13:39 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:57386) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V45zs-0000sZ-CL for 14964@debbugs.gnu.org; Tue, 30 Jul 2013 05:13:36 -0400 Original-Received: from [62.47.57.78] ([62.47.57.78]) by mail.gmx.com (mrgmx002) with ESMTPA (Nemesis) id 0MYOkT-1UZ8rj1vu5-00VCGe for <14964@debbugs.gnu.org>; Tue, 30 Jul 2013 11:13:30 +0200 In-Reply-To: <8c5571e7-7ce2-4581-a2e6-8026ddcd0e3c@default> X-Provags-ID: V03:K0:IioCX+aeLd6sRwr2BDdzVnV3mj/g1RpppsktIZGlZGhO5cRYTaS FlJhYMXw+QN+VzrNlpNJ6IT9eKCLidMRYQ5eKxO4Q7mTgYFmEwfMgkWX/Z8iL+WRuyYF5mT rZUzvu7XaxO5tziKsPNprLUYkpKUhZFD4UkDQM2/iayzLGZtwEB/r2eUln4YZTIJoM3wrUx dY5dHASy4WqaIz9+GgIJw== 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:76793 Archived-At: > Is there some internal use of Emacs window and frame configurations? The main purpose of window configurations is with implementing `save-window-excursion'. > 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-*'? Speed, I think. `save-window-excursion' is (unfortunately) used much too often in order to compromise its behavior. Saving and restoring a frame configurations doesn't do any size checking, window splitting, suppression of associated error messages - it does its job as quickly as possible. For this purpose, a stored window configuration inhibits the collection of its window objects so it doesn't have to create them anew. > 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. If I had wanted to document that, I would have added the above text to the doc-string of `window-state-get'. > A proper, documented structure (whether list or defstruct) is what I would > like to see instead. Then please, please write one. We all would have to start from scratch doing that. And you know best what you want to see. > 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'). Where would you like to see that? That's a C structure without any Lisp equivalent. It would have to go to the Window Internals section but that one is far from accurate. Window configurations have been devised to restore a previous frame state in one and the same session. Otherwise they were completely opaque. Window states have been devised to restore a previous frame state in another session and are opaque as well. Looking into such objects, documenting them accurately and providing routines to convert one into the other would be quite beneficial for both - users and developers. But this should be really done by someone who wants to exploit and test the results in actual code. martin