From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: GUI vs TTY when saving & restoring framesets Date: Mon, 23 Jan 2017 15:15:52 +0100 Message-ID: References: <834m0r5aiu.fsf@gnu.org> <83d1fe4fcq.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f403045d5d7289f78e0546c3a597 X-Trace: blaine.gmane.org 1485181013 29883 195.159.176.226 (23 Jan 2017 14:16:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2017 14:16:53 +0000 (UTC) Cc: Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 15:16:44 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 1cVfQF-0006ru-Rq for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2017 15:16:40 +0100 Original-Received: from localhost ([::1]:42363 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVfQK-0004Eh-R5 for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2017 09:16:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVfQD-0004AO-U1 for emacs-devel@gnu.org; Mon, 23 Jan 2017 09:16:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVfQC-0003oA-NJ for emacs-devel@gnu.org; Mon, 23 Jan 2017 09:16:37 -0500 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:37129) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cVfQA-0003nS-Ne; Mon, 23 Jan 2017 09:16:34 -0500 Original-Received: by mail-wm0-x22d.google.com with SMTP id c206so157662172wme.0; Mon, 23 Jan 2017 06:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/F74F/Weay5pxq7dEmA0bwjkrGqBwXIdlvvXVKs0eoM=; b=qzpb2BosyysSZdVdv/jq7yqjBPP2qW7jTDWQMrZ8y0udCL0QCbJP1GD/RYxYgDpllE iVh9SVO2JN4gTcnLjWZVNM+yDhPJJ8yrLzHfQN7/ieRXZdz6QrS5LGvCeny0CoPRyNNG npHhnAMZu7CBUzA+KzLasIhKnq/Hn57HrTeZT4XceFU7coYs7jg3CTzsOxIvyxKgMfZe wBlSUMYdcbNn8izkA138xYPz/mjoWtg4J+ipf49FD34AWKME4wT0EirCnEs25PIqy7PF 77Yh4i77xs0ahFZ4bKU23Pzd7mcCR7sn3O56XD+FGxbe2NA1JZoLxNLUc+PYmQ4euDym lJiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/F74F/Weay5pxq7dEmA0bwjkrGqBwXIdlvvXVKs0eoM=; b=H53VbYG1G63HKmtyy0ZW+khzuSZxMSbqEGkD46vf/Q0ylLvkH/G0oWD9dlf9vxiU5J n89LbzYPkfDPFOUThSPsXfceOZ5lexKoy7nPViDDDuNx+o9afodW6jIfpDsABO4OWb7j fR6s2uGQCb8tYRwviBEwS5OAYlyi7uQP+fVUKHEozQvPS17IJwqbIdvdi+V0E11Vcnj0 +NDVUxCfUrEjlcVI86qSjH1iKsGOV28MuJPhgrcMTzX/jiY8OCArHngjvIO/vLHzAuCr GJx6LrQmJ0d5gKtGidMMF3mnytohNUI4eiA2i+LUjqeiydctGeK6PrqCA3j4kXguQX/6 416Q== X-Gm-Message-State: AIkVDXJbmEtBp3RPx55MrpRH8NQzj7o699rLRz4CHPsVziJoEedIeRS9z6RePHDoZqRHJHoeSvss5aKK8qCQ+Q== X-Received: by 10.223.153.15 with SMTP id x15mr23963471wrb.179.1485180993401; Mon, 23 Jan 2017 06:16:33 -0800 (PST) Original-Received: by 10.194.172.129 with HTTP; Mon, 23 Jan 2017 06:15:52 -0800 (PST) In-Reply-To: <83d1fe4fcq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22d 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:211576 Archived-At: --f403045d5d7289f78e0546c3a597 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 4:36 AM, Eli Zaretskii wrote: > 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. 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. Currently, if you have an emacs GUI instance with frames A, B, and C. exit it, then enter a -nw session, frameset-restore tries to create frames A', B' and C' which share as many characteristics from A, B and C as possible. Obviously not size or position, but windows, buffers shown in them, etc. Then you return to GUI and get back A, B and C (assuming the -nw session didn't change or delete them). Well, it's not what happens *now*, but it is how the code was designed to perform. But, is that what the user expects? Wouldn't it be easier to keep these kinds of sessions apart? Additionally, frameset.el is designed to allow manipulation of framesets as objects, meaning that nothing precludes saving several of them (either in the desktop save file, or another file) with some kind of user identifier (a name or whatever) and then restoring on demand the desired frameset. It's just that desktop.el takes the easiest route, which is to save and restore a single frameset. But perhaps this isn't how we should be doing it. All of this (bugs aside) is easy to implement, but before changing one line of code we should know what we want. > 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. --f403045d5d7289f78e0546c3a597 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 23, 2017 at 4:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> That&= #39;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 c= an 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 f= rame from a -nw session, and then exits and reenters Emacs in -nw mode. Sho= uldn't the GUI frame be restored too? We haven't decided (likely be= cause the issue didn't present itself earlier than that bug report) how= to deal when running mixed frames' instances.

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 s= ave the GUI frameset and the -nw frameset as distinct entities in the deskt= op file, and just restore the one appropriate. No mixing.

Currently, if you have an emacs GUI instance with frames A, B, and = C. exit it, then enter a -nw session, frameset-restore tries to create fram= es A', B' and C' which share as many characteristics from A, B = and C as possible. Obviously not size or position, but windows, buffers sho= wn in them, etc. Then you return to GUI and get back A, B and C (assuming t= he -nw session didn't change or delete them). Well, it's not what h= appens *now*, but it is how the code was designed to perform.
But, is that what the user expects? Wouldn't it be easier t= o keep these kinds of sessions apart?

Additionally= , frameset.el is designed to allow manipulation of framesets as objects, me= aning that nothing precludes saving several of them (either in the desktop = save file, or another file) with some kind of user identifier (a name or wh= atever) and then restoring on demand the desired frameset. It's just th= at desktop.el takes the easiest route, which is to save and restore a singl= e frameset. But perhaps this isn't how we should be doing it.

All of this (bugs aside) is easy to implement, but before c= hanging one line of code we should know what we want.

<= div>> Because the original code had worse problems, and we didn't kn= ow how
> to fix it better than that.

<= div>Wouldn't want anyone to believe that I was complaining or belittlin= g 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.

--f403045d5d7289f78e0546c3a597--