From: Juanma Barranquero <lekktu@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: 14964@debbugs.gnu.org
Subject: bug#14964: 24.3.50; doc of `compare-window-configurations'
Date: Tue, 30 Jul 2013 02:18:59 +0200 [thread overview]
Message-ID: <CAAeL0SRw0uKpEYBU1uH3Ji0eKY6KSs-Ni7M3Hy=1aPcCKu0NOg@mail.gmail.com> (raw)
In-Reply-To: <8c5571e7-7ce2-4581-a2e6-8026ddcd0e3c@default>
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
next prev parent reply other threads:[~2013-07-30 0:18 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 [this message]
2013-07-30 9:13 ` martin rudalics
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAeL0SRw0uKpEYBU1uH3Ji0eKY6KSs-Ni7M3Hy=1aPcCKu0NOg@mail.gmail.com' \
--to=lekktu@gmail.com \
--cc=14964@debbugs.gnu.org \
--cc=drew.adams@oracle.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.