Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii <eliz@gnu.org>]

> 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