From: Eli Zaretskii <eliz@gnu.org>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: GUI vs TTY when saving & restoring framesets
Date: Sun, 22 Jan 2017 18:23:21 +0200 [thread overview]
Message-ID: <834m0r5aiu.fsf@gnu.org> (raw)
In-Reply-To: <CAAeL0SRNXFW5WPFYS6FHE_Ffggj37CgnL-Ptz3dv91JotA1beg@mail.gmail.com> (message from Juanma Barranquero on Sun, 22 Jan 2017 05:21:44 +0100)
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 22 Jan 2017 05:21:44 +0100
>
> 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.
Bug #17693 demonstrated that the feature you like had some negative
consequences, and in particular that some users did expect -nw to
affect how desktop is restored in the -nw invocation. We were unable
to find a solution better than the one committed for that bug.
Bug #24298 then reported an unintended consequence of the fix for
17693, whereby desktop.el was changed not to restore the frameset, but
wasn't told about that, so some portions of the code still acted as if
the frameset was restored, and produced annoying behavior as result.
The fix was to disable frameset restoration under -nw more thoroughly.
> 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?
If you can find a way of fixing 17693 without disabling frameset
restoration, feel free to do that on master. Given user feedback we
have, I think we should not create GUI frames when Emacs is invoked
with -nw, though, at least by default. (We could have a user option
to countermand that, if you think some users will want that.)
As for the trips in frameset.el, I don't think they are entirely
redundant, because I'd expect the following sequence of Emacs
invocations to re-create the original GUI frames from the 1st
invocation:
. emacs
. emacs -nw
. emacs
next prev parent reply other threads:[~2017-01-22 16:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-22 4:21 GUI vs TTY when saving & restoring framesets Juanma Barranquero
2017-01-22 4:23 ` 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 [this message]
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=834m0r5aiu.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.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 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).