[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14964: 24.3.50; doc of `compare-window-configurations'
From: |
Juanma Barranquero |
Subject: |
bug#14964: 24.3.50; doc of `compare-window-configurations' |
Date: |
Tue, 30 Jul 2013 02:18:59 +0200 |
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
- bug#14964: 24.3.50; doc of `compare-window-configurations', (continued)
- bug#14964: 24.3.50; doc of `compare-window-configurations', martin rudalics, 2013/07/28
- bug#14964: 24.3.50; doc of `compare-window-configurations', Drew Adams, 2013/07/28
- bug#14964: 24.3.50; doc of `compare-window-configurations', Juanma Barranquero, 2013/07/28
- bug#14964: 24.3.50; doc of `compare-window-configurations', Drew Adams, 2013/07/28
- bug#14964: 24.3.50; doc of `compare-window-configurations', Juanma Barranquero, 2013/07/28
- bug#14964: 24.3.50; doc of `compare-window-configurations', Drew Adams, 2013/07/29
- bug#14964: 24.3.50; doc of `compare-window-configurations', Juanma Barranquero, 2013/07/29
- bug#14964: 24.3.50; doc of `compare-window-configurations', martin rudalics, 2013/07/30
- bug#14964: 24.3.50; doc of `compare-window-configurations', martin rudalics, 2013/07/29
- bug#14964: 24.3.50; doc of `compare-window-configurations', Drew Adams, 2013/07/29
- bug#14964: 24.3.50; doc of `compare-window-configurations',
Juanma Barranquero <=
- bug#14964: 24.3.50; doc of `compare-window-configurations', martin rudalics, 2013/07/30
- bug#14964: 24.3.50; doc of `compare-window-configurations', Stefan Monnier, 2013/07/30
- bug#14964: 24.3.50; doc of `compare-window-configurations', Josh, 2013/07/28
- bug#14964: 24.3.50; doc of `compare-window-configurations', Drew Adams, 2013/07/28
- bug#14964: 24.3.50; doc of `compare-window-configurations', martin rudalics, 2013/07/29