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: Mon, 23 Jan 2017 17:49:12 +0200 Message-ID: <838tq14w07.fsf@gnu.org> References: <834m0r5aiu.fsf@gnu.org> <83d1fe4fcq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485186606 28537 195.159.176.226 (23 Jan 2017 15:50:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2017 15:50:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 16:50:00 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 1cVgs2-0004XI-Sd for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2017 16:49:26 +0100 Original-Received: from localhost ([::1]:42777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVgs8-0007UL-57 for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2017 10:49:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVgrx-0007QD-7y for emacs-devel@gnu.org; Mon, 23 Jan 2017 10:49:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVgrt-00033W-96 for emacs-devel@gnu.org; Mon, 23 Jan 2017 10:49:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVgrt-00033S-5q; Mon, 23 Jan 2017 10:49:17 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4570 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cVgrs-0006As-G8; Mon, 23 Jan 2017 10:49:16 -0500 In-reply-to: (message from Juanma Barranquero on Mon, 23 Jan 2017 15:15:52 +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:211577 Archived-At: > From: Juanma Barranquero > Date: Mon, 23 Jan 2017 15:15:52 +0100 > Cc: Emacs developers > > > That's fine with me, but if you read bug#17693, you will see that the > > original report there explicitly describes a situation where GUI > > frames were created by restoring desktop in a -nw session. > > It wasn't the intention. OTOH, as a -nw session on GNU/Linux can have both GUI and tty frames, I'm not sure > it is a bug, just we're entering unspecified territory. I mean, what if the user creates a GUI frame from a -nw > session, and then exits and reenters Emacs in -nw mode. Shouldn't the GUI frame be restored too? We > haven't decided (likely because the issue didn't present itself earlier than that bug report) how to deal when > running mixed frames' instances. A I've said earlier, if we think different users might want different behavior in this respect, we should have a customizable option. In any case, the simplest case should work as expected: when the desktop file records only one frame, it shall be restored as a single text-mode frame when Emacs is started with -nw, I think. > Thinking about these issues, I suddenly realized that, if we were to treat -nw and GUI sessions as different > (frameset-wise, I mean), we could just save the GUI frameset and the -nw frameset as distinct entities in the > desktop file, and just restore the one appropriate. No mixing. I'm not sure this is desirable. It is IMO more natural to have the same frameset for all sessions. But that's me. Full disclosure: I never restore my sessions into Emacs started with -nw, except for testing these issues. > All of this (bugs aside) is easy to implement, but before changing one line of code we should know what we > want. Frame restoration is a relatively recent feature, so I think we should first make sure it works correctly in the simple scenarios, before we start extending it to support more exotic ones. As one data point, I don't think anyone has yet requested the features you describe above. > > Because the original code had worse problems, and we didn't know how > > to fix it better than that. > > Wouldn't want anyone to believe that I was complaining or belittling you or anyone who had to deal with these > bugs, I'm deeply sorry. Not my intention at all. It's me who wrote the code and went MIA. My fault entirely. I didn't write the above to assign blame. We just did as best we could, under pressure from a looming release.