From: Juanma Barranquero <lekktu@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: frameset-to-register
Date: Mon, 5 Aug 2013 22:49:00 +0200 [thread overview]
Message-ID: <CAAeL0SRAquVY62AsqdMPbfNfb_KyQy6TORG1eWJKipNxrPXEVQ@mail.gmail.com> (raw)
In-Reply-To: <cbfd37e5-d8f9-4dd5-991d-d9b3c896face@default>
On Mon, Aug 5, 2013 at 10:35 PM, Drew Adams <drew.adams@oracle.com> wrote:
> Why does this not just replace `frame-configuration-to-register', i.e.,
> C-x r f? What are the differences? In particular, what, if anything,
> does `frame-configuration-to-register' let you do that
> `frameset-to-register' does not let you do?
I don't know, and that's the point. I've used
frame-configuration-to-register all of perhaps ten times, eight or so
just to test something. I think it makes more sense to leave both
options and let the user choose.
> I understand that a frameset is Lisp-readable, so it can be persisted.
Caveat user. The frameset I'm using for frameset-to-register is not
really "Lisp-readable", because I've opted to filter out as few frame
parameters as possible. That means that non-readable parameters, like
buffer-list, are kept. Why? Because frameset-to-register, like
frame-configuration-to-register, is an in-session command, and keeping
links to live (or dead) objects provides a better in-session user
experience. If someone someday decides to save to disk the frameset
contained in a register, we'll have to add code to filter out
additional parameters (should be trivial, once the use case is clearly
defined).
> But it's not clear why one would use `frame-configuration-to-register'
> if `frameset-to-register' is now available.
Perhaps you don't want dead frames to come back to life.
> I can guess that `frame-configuration-to-register' might be quicker,
> but what are the real, user-level differences that would mean that a
> user might want both to be available (and bound to keys)?
You try and tell me ;-)
J
next prev parent reply other threads:[~2013-08-05 20:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 5:12 frameset-to-register Juanma Barranquero
2013-08-05 13:11 ` frameset-to-register Juanma Barranquero
2013-08-05 20:35 ` frameset-to-register Drew Adams
2013-08-05 20:49 ` Juanma Barranquero [this message]
2013-08-06 21:11 ` frameset-to-register Stefan Monnier
2013-08-08 0:49 ` frameset-to-register Juanma Barranquero
-- strict thread matches above, loose matches on Subject: below --
2014-02-12 22:59 frameset-to-register Juanma Barranquero
2014-02-13 0:34 ` frameset-to-register Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAeL0SRAquVY62AsqdMPbfNfb_KyQy6TORG1eWJKipNxrPXEVQ@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).