all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Mon, 23 Jan 2017 17:49:12 +0200	[thread overview]
Message-ID: <838tq14w07.fsf@gnu.org> (raw)
In-Reply-To: <CAAeL0SQcAONrk4UZKtG2J0j2CGOAdRBfqOwNVYgO9TvjRuxCPg@mail.gmail.com> (message from Juanma Barranquero on Mon, 23 Jan 2017 15:15:52 +0100)

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 23 Jan 2017 15:15:52 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > 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.



  reply	other threads:[~2017-01-23 15:49 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=838tq14w07.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.