From: Juanma Barranquero <lekktu@gmail.com>
To: Emacs developers <emacs-devel@gnu.org>
Subject: GUI vs TTY when saving & restoring framesets
Date: Sun, 22 Jan 2017 05:21:44 +0100 [thread overview]
Message-ID: <CAAeL0SRNXFW5WPFYS6FHE_Ffggj37CgnL-Ptz3dv91JotA1beg@mail.gmail.com> (raw)
I've seen that there were several bugs related to framesets and ttys
(I've located bug#17693 and bug#24298, but there were perhaps others).
I don't understand yet the problems and the way they were fixed, but
it has changed one previous feature.
You could do
(1) emacs -f desktop-save-mode -f destop-read
set up your frame configuration with a couple of frames, save the desktop, then
(2) emacs -f desktop-save-mode -f desktop-read -nw
and you would get the same number of frames, then again
(3) emacs -f desktop-save-mode -f desktop-read -nw
and you would get back the original graphics frames.
As of the current trunk, assuming you had 2 frames in (1), when you do
(2) you gent a message
Desktop: 2 frames, 0 buffers restored.
which I think is false, because "C-x 5 o" does not switch to F2. Then,
if you exit emacs, (3) produces a warning "Error (frameset): Font
'tty' is not defined.
So, basically, previously the frameset saving in desktop.el was
intended to be unaffected by -nw (per se; of course changes to the
frames would be reflected in subsequent configurations, but not just
entering and exiting -nw), and now it's not.
I sort of liked the previous behavior, which was (bugs aside) safer.
But if the new behavior is preferred, I think there's quite a lot of
code from frameset.el that deals with the gui -> tty -> gui trip and
could be excised.
Opinions?
next reply other threads:[~2017-01-22 4:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-22 4:21 Juanma Barranquero [this message]
2017-01-22 4:23 ` GUI vs TTY when saving & restoring framesets Juanma Barranquero
2017-01-22 13:27 ` Alan Mackenzie
2017-01-22 16:31 ` Eli Zaretskii
2017-01-22 18:00 ` Alan Mackenzie
2017-01-22 18:14 ` Eli Zaretskii
2017-01-22 18:55 ` Alan Mackenzie
2017-01-22 19:11 ` Eli Zaretskii
2017-01-22 19:38 ` Alan Mackenzie
2017-01-22 20:03 ` Eli Zaretskii
2017-01-22 20:44 ` Alan Mackenzie
2017-01-22 21:06 ` Juanma Barranquero
2017-01-23 17:39 ` Andreas Schwab
2017-01-23 18:02 ` martin rudalics
2017-01-22 16:23 ` Eli Zaretskii
2017-01-22 21:15 ` Juanma Barranquero
2017-01-23 3:36 ` Eli Zaretskii
2017-01-23 14:15 ` Juanma Barranquero
2017-01-23 15:49 ` Eli Zaretskii
2017-01-23 16:14 ` Juanma Barranquero
2017-01-23 16:16 ` 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=CAAeL0SRNXFW5WPFYS6FHE_Ffggj37CgnL-Ptz3dv91JotA1beg@mail.gmail.com \
--to=lekktu@gmail.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).