bug#14964: 24.3.50; doc of `compare-window-configurations'

[Drew Adams <drew.adams@oracle.com>]

>  > E.g. (current-frame-configuration t) would return a writable & readable
>  > frame configuration.
> 
> 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.
> 
>  > But the point is to have a standard structure that code can use and
>  > manipulate.
> 
> 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.