unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>
Cc: Juanma Barranquero <lekktu@gmail.com>, 14964@debbugs.gnu.org
Subject: bug#14964: 24.3.50; doc of `compare-window-configurations'
Date: Tue, 30 Jul 2013 11:13:20 +0200	[thread overview]
Message-ID: <51F783B0.2030303@gmx.at> (raw)
In-Reply-To: <8c5571e7-7ce2-4581-a2e6-8026ddcd0e3c@default>

 > 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





  parent reply	other threads:[~2013-07-30  9:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-27  3:14 bug#14964: 24.3.50; doc of `compare-window-configurations' Drew Adams
2013-07-27  8:18 ` martin rudalics
2013-07-27 19:39   ` Drew Adams
2013-07-28  8:40     ` martin rudalics
2013-07-28 14:49       ` Drew Adams
2013-07-28 16:57         ` Juanma Barranquero
2013-07-28 18:56           ` Drew Adams
2013-07-29  2:14             ` Juanma Barranquero
2013-07-29 23:56               ` Drew Adams
2013-07-30  1:05                 ` Juanma Barranquero
2013-07-30  9:13                 ` martin rudalics
2013-07-29  7:55             ` martin rudalics
2013-07-29 23:53               ` Drew Adams
2013-07-30  0:18                 ` Juanma Barranquero
2013-07-30  9:13                 ` martin rudalics [this message]
2013-07-30 14:17                   ` Stefan Monnier
2013-07-28 19:53           ` Josh
2013-07-28 20:33             ` Drew Adams
2013-07-29  7:54         ` martin rudalics
2022-04-21 13:42   ` Lars Ingebrigtsen
2022-05-20  2:23     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F783B0.2030303@gmx.at \
    --to=rudalics@gmx.at \
    --cc=14964@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=lekktu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).