From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GUI vs TTY when saving & restoring framesets Date: Sun, 22 Jan 2017 18:23:21 +0200 Message-ID: <834m0r5aiu.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485102268 8020 195.159.176.226 (22 Jan 2017 16:24:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2017 16:24:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 22 17:24:22 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVKw2-0000Pd-Ne for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2017 17:24:06 +0100 Original-Received: from localhost ([::1]:36883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVKw7-0001vB-S5 for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2017 11:24:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVKvW-0001us-AW for emacs-devel@gnu.org; Sun, 22 Jan 2017 11:23:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVKvS-0007iP-6i for emacs-devel@gnu.org; Sun, 22 Jan 2017 11:23:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVKvS-0007hh-3J; Sun, 22 Jan 2017 11:23:30 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3783 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cVKvM-00058e-Un; Sun, 22 Jan 2017 11:23:25 -0500 In-reply-to: (message from Juanma Barranquero on Sun, 22 Jan 2017 05:21:44 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211529 Archived-At: > From: Juanma Barranquero > 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