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

[Juanma Barranquero <lekktu@gmail.com>]

On Tue, Jul 30, 2013 at 1:53 AM, Drew Adams <drew.adams@oracle.com> wrote:

> 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),

I'm currently separating the frame-state code into a new package
(surprisingly named frame-state.el) which does not depend on
desktop.el at all. desktop.el will be a client of it (the main client,
I'd say). One of the goals is to make frame-state a bit less dependent
on global state, though removing all such is impractical.

The new format for frame states is

  (frame-state PROPLIST (FRAME-STATE WINDOW-STATE)...)

where `frame-state' is a symbol, and PROPLIST is a property list. The
only defined keyword is :version, which will be 1 and would be
increased if the format were modified. Additional properties can be
added by the user when creating a frame-state. Two that spring to mind
would be :name (a readable name) and :id (a md5 or random key or
whatever to simplify comparing two frame-states). FRAME-STATE and
WINDOW-STATE are as now: a frame parameter list and the output of
window-state-get.

> if possible unify it with the existing frame-configuration functions
> (`current-frame-configuration', `set-frame-configuration',
> `frame-configuration-p', `frame-configuration-to-register').

Not possible. current-frame-configuration has no arguments, just
"freezes" the current frame configuration. frame-set-save has at least
two arguments (a frame-list to limit the frames being considered, and
a filter-alist which will default to frame-state-filter-alist
(previously known as desktop-filter-frame-params-alist). I'm in the
middle of coding this, so it is possible that I end adding more args.

frame-state-restore has still more arguments, to select the restoring
behavior that is currently set via desktop-* customizable options
(desktop will keep these options, which will be the source of the
args, though they don't have to be identical and the correspondence is
not necessarily one-to-one; let's see).

frame-state-p is trivial:

(defun frame-state-p (frame-state)
  "If FRAME-STATE is a frame-state, return its :version.
Else return nil."
  (and (eq (car-safe frame-state) 'frame-state)
       (plist-get (cl-second frame-state) :version)))

and `frame-state-to-register' should be equally easy.

> 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).

It's not clear to me either, but I see enough differences to remain
deeply unconvinced.

> 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.

I wouldn't say "quite a bit more". The minibuffer relationships, and
also some frame state (position, size, fullscreen state, font, a few
other parameters) which must be protected in case the user restores in
a tty.

> 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.

At the moment, the readable frame-config format simply does not exist,
so I'm not going to worry about being similar or different to it.
Sorry.

   J