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

[Juanma Barranquero]

On Sun, Jul 28, 2013 at 4:49 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Yes, I am hoping exactly that.  His work with desktop.el will apparently use
> Lisp-readable representations of sets of frames.  I hope this will be
> applied/extended to the frame-configuration functions, so we can optionally
> get Lisp-readable frame configurations (with the same properties and
> interfaces as we have now).

I think frame configurations are a bit underdocumented. Also, I'm not
sure what do they record and how that differs of what I've had to
implement for desktop.el (other than the fact that with frame
configurations you cannot restore a deleted frame, and you can with
desktop frame-states).

In particular, according to current-frame-configuration's docstring:

  Its car is `frame-configuration'.
  Each element of the cdr is a list of the form (FRAME ALIST WINDOW-CONFIG),
  where
    FRAME is a frame object,
    ALIST is an association list specifying some of FRAME's parameters, and
    WINDOW-CONFIG is a window configuration object for FRAME."

- FRAME, as a frame object, can not be serialized to disk. Serializing
it means serializing its contents and attributes, as I try to do in
desktop.el.
- ALIST specifies "some of FRAME's parameters", but it doesn't say
which ones, or the criteria used to select them, or why these
parameters are important and not others.
- WINDOW-CONFIG is also not serializable, but Martin's
window-state-(get|put) does something similar.

So, what do you expect of "Lisp-readable frame configurations"? A Lisp
readable frame configuration is not very different of a desktop
frame-state, and any function that serializes it will necessarily do
something similar to desktop-save-frames (details of output format can
vary, of course). Which differences are you're interested in? (Other
than the currrent API of desktop-save-frames being currently not very
reuse-friendly, I mean.)

IIUC, what you would do is, either add parameters to the current
frame-configuration functions to obtain a serializable config, or add
a serialize-frame-config function. Isn't that more or less what I've
been doing? If there is information that frame-configuration saves and
desktop-save-frames does not, and is information that can be
meaningfully restored in another Emacs session, we can discuss adding
it.

> E.g., a frame config would continue to look like this, even when
> Lisp-readable:
>
> (frame-configuration FRAME+WINDOW-CONFIG...)
>
> where FRAME+WINDOW-CONFIG would be a Lisp-readable representation of a frame
> (a set of frame parameters, preferably at least the same ones recorded now)
> plus the frame's window configuration.

I see your little trick here ;-) A frame configuration is not the
configuration of a frame, but of all existing frames. So a serialized
frame configuration would be

(frame-configuration (FRAME+WINDOW-CONFIG)...)

and that's just syntactic sugar over what a desktop frame-state
currently is: ((FRAME-PARAMS . WINDOW-STATE)...)

> Let me know if you (e.g. Juanma) prefer that I file this as a separate
> bug (enhancement request).  If so, I will, repeating what I've said here.

No, I just want to understand what is being requested. In other words,
the API that does not exist currently and you'd like to see.

> a. these structures documented, i.e., the structure advertised as such, or
> b. access functions defined for their parts.

I'd like to see that, too.

> IOW, either an open, advertised structure or a black box but providing
> advertised ways to get at the various components.

As previously discussed, in private and in my last emacs-devel
message, I'm open to that but I don't think that providing an API to
serialize individual frames makes much sense. But ways to make
desktop-save-frames more open and accesible? Definitely I'm in.

    J