GUI vs TTY when saving & restoring framesets

GUI vs TTY when saving & restoring framesets

[Juanma Barranquero]

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.

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?

Re: GUI vs TTY when saving & restoring framesets

[Juanma Barranquero]

On Sun, Jan 22, 2017 at 5:21 AM, Juanma Barranquero <lekktu@gmail.com> wrote:

> (3)  emacs -f desktop-save-mode -f desktop-read -nw

I meant this, of course:

(3)  emacs -f desktop-save-mode -f desktop-read

Re: GUI vs TTY when saving & restoring framesets

[Alan Mackenzie]

Hello, Juanma.

On Sun, Jan 22, 2017 at 05:21:44 +0100, Juanma Barranquero wrote:
> 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.

To those bugs I would add:
#23630: Emacs 25.0.94.1: desktop-read loads buffers in the wrong order.
#19706: Emacs 25.0.50; (+ nil nil -1) in desktop-restore-frameset

They have relevance to tty vs. GUI, although they might not be
restricted to that difference.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii]

> Date: Sun, 22 Jan 2017 13:27:27 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> To those bugs I would add:
> #23630: Emacs 25.0.94.1: desktop-read loads buffers in the wrong order.
> #19706: Emacs 25.0.50; (+ nil nil -1) in desktop-restore-frameset

When were those last tried?  Is it possible that they are fixed on the
release branch?

FWIW, when I finished working on bug#24298, I no longer saw incorrect
order of buffers after restoring the desktop: their order was always
the same, as long as I restored from the same desktop file.  Maybe you
just don't like the order in which desktop.el puts them in the desktop
file?

Re: GUI vs TTY when saving & restoring framesets

[Alan Mackenzie]

Hello, Eli.

On Sun, Jan 22, 2017 at 18:31:54 +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Jan 2017 13:27:27 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Emacs developers <emacs-devel@gnu.org>

> > To those bugs I would add:
> > #23630: Emacs 25.0.94.1: desktop-read loads buffers in the wrong order.
> > #19706: Emacs 25.0.50; (+ nil nil -1) in desktop-restore-frameset

> When were those last tried?  Is it possible that they are fixed on the
> release branch?

#19706 had a workaround applied to it, I think.  (I think I did this
myself)
#23630 is not fixed.  I've just tried it.....

> FWIW, when I finished working on bug#24298, I no longer saw incorrect
> order of buffers after restoring the desktop: their order was always
> the same, as long as I restored from the same desktop file.  Maybe you
> just don't like the order in which desktop.el puts them in the desktop
> file?

... on master.  I had four frames open, cycled through them, then did
C-x C-c, creating the desktop file and exiting.

I restarted Emacs, which created the four frames, and then did C-x C-b.
The second entry there was *scratch*.  This was not any of the four
buffers which were in the frames' windows when I previously shut down.

Other than that, the order of the buffers in C-x C-b is the reverse of
the order in my desktop file.

This was in GNU, X-Windows, with desktop-restore-frames set to t, using
version 208 (i.e. Emacs >= 25) of the desktop file format.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii]

> Date: Sun, 22 Jan 2017 18:00:10 +0000
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> #23630 is not fixed.  I've just tried it.....
> 
> > FWIW, when I finished working on bug#24298, I no longer saw incorrect
> > order of buffers after restoring the desktop: their order was always
> > the same, as long as I restored from the same desktop file.  Maybe you
> > just don't like the order in which desktop.el puts them in the desktop
> > file?
> 
> ... on master.  I had four frames open, cycled through them, then did
> C-x C-c, creating the desktop file and exiting.
> 
> I restarted Emacs, which created the four frames, and then did C-x C-b.
> The second entry there was *scratch*.  This was not any of the four
> buffers which were in the frames' windows when I previously shut down.

??? The *scratch* buffer is created in any Emacs session regardless of
the saved desktop.  So why isn't the above TRT?  When did Emacs and
desktop.el behave differently?

> Other than that, the order of the buffers in C-x C-b is the reverse of
> the order in my desktop file.

Why is that a problem?  The order of buffers in the desktop file is
not something a user is supposed to look at, or care about.

Re: GUI vs TTY when saving & restoring framesets

[Alan Mackenzie]

Hello, Eli.

On Sun, Jan 22, 2017 at 20:14:03 +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Jan 2017 18:00:10 +0000
> > Cc: lekktu@gmail.com, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > #23630 is not fixed.  I've just tried it.....

> > > FWIW, when I finished working on bug#24298, I no longer saw incorrect
> > > order of buffers after restoring the desktop: their order was always
> > > the same, as long as I restored from the same desktop file.  Maybe you
> > > just don't like the order in which desktop.el puts them in the desktop
> > > file?

> > ... on master.  I had four frames open, cycled through them, then did
> > C-x C-c, creating the desktop file and exiting.

> > I restarted Emacs, which created the four frames, and then did C-x C-b.
> > The second entry there was *scratch*.  This was not any of the four
> > buffers which were in the frames' windows when I previously shut down.

> ??? The *scratch* buffer is created in any Emacs session regardless of
> the saved desktop.  So why isn't the above TRT?  When did Emacs and
> desktop.el behave differently?

In All Emacsen up to Emacs 25, *scratch is right at the bottom of the
buffer list, where it won't get in the way.

> > Other than that, the order of the buffers in C-x C-b is the reverse of
> > the order in my desktop file.

> Why is that a problem?  The order of buffers in the desktop file is
> not something a user is supposed to look at, or care about.

I care a great deal about it.  I have set up keys <f1> to <f11> in the
global key map to mean "switch to frame Fn".  Thus, rather than just
being an arbitrary GUI window, each frame is associated with a particular
function key.  I even have "Fn" in the mode line to see which frame I'm
in.

Usually when I close an Emacs session, I quickly type <f6>, <f5>, ....,
<f1> to order the buffers in my .emacs.desktop.  When I start Emacs (in a
Linux tty, usually, with desktop-restore-frames nil) I do, repeatedly,
C-x 5 b <cr> to set up the same buffers in the "same" frames.  For this,
I need the buffers to be loaded in the right order, WITHOUT *scratch* as
an interloper.  At the moment, this isn't happening in master in some
circumstances.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii]

> Date: Sun, 22 Jan 2017 18:55:37 +0000
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > the order in my desktop file.
> 
> > Why is that a problem?  The order of buffers in the desktop file is
> > not something a user is supposed to look at, or care about.
> 
> I care a great deal about it.  I have set up keys <f1> to <f11> in the
> global key map to mean "switch to frame Fn".  Thus, rather than just
> being an arbitrary GUI window, each frame is associated with a particular
> function key.  I even have "Fn" in the mode line to see which frame I'm
> in.
> 
> Usually when I close an Emacs session, I quickly type <f6>, <f5>, ....,
> <f1> to order the buffers in my .emacs.desktop.  When I start Emacs (in a
> Linux tty, usually, with desktop-restore-frames nil) I do, repeatedly,
> C-x 5 b <cr> to set up the same buffers in the "same" frames.  For this,
> I need the buffers to be loaded in the right order, WITHOUT *scratch* as
> an interloper.  At the moment, this isn't happening in master in some
> circumstances.

I don't really understand the need for this.  I always have several
frames in my sessions, each one with its buffer, and when I restore
the sessions, each frame comes up with the same buffer it had when I
shut down Emacs, no complicated frame-walking dance necessary, neither
before shutting down Emacs nor after restarting it.  Maybe this stuff
you do is the culprit?

Re: GUI vs TTY when saving & restoring framesets

[Alan Mackenzie]

Hello, Eli.

On Sun, Jan 22, 2017 at 21:11:03 +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Jan 2017 18:55:37 +0000
> > Cc: lekktu@gmail.com, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > the order in my desktop file.

> > > Why is that a problem?  The order of buffers in the desktop file is
> > > not something a user is supposed to look at, or care about.

> > I care a great deal about it.  I have set up keys <f1> to <f11> in the
> > global key map to mean "switch to frame Fn".  Thus, rather than just
> > being an arbitrary GUI window, each frame is associated with a particular
> > function key.  I even have "Fn" in the mode line to see which frame I'm
> > in.

> > Usually when I close an Emacs session, I quickly type <f6>, <f5>, ....,
> > <f1> to order the buffers in my .emacs.desktop.  When I start Emacs (in a
> > Linux tty, usually, with desktop-restore-frames nil) I do, repeatedly,
> > C-x 5 b <cr> to set up the same buffers in the "same" frames.  For this,
> > I need the buffers to be loaded in the right order, WITHOUT *scratch* as
> > an interloper.  At the moment, this isn't happening in master in some
> > circumstances.

> I don't really understand the need for this.

I need to be able to switch quickly between (specific) frames using the
keyboard.  And by quickly I mean QUICKLY.  There's no method faster than
with a single key press.  It's just the way I work.

> I always have several frames in my sessions, each one with its buffer,
> and when I restore the sessions, each frame comes up with the same
> buffer it had when I shut down Emacs, no complicated frame-walking
> dance necessary, neither before shutting down Emacs nor after
> restarting it.

Something similar happens when I use the defaults.  But the buffers come
up in the "wrong" frames (i.e. associated with a different <fn> key),
making it not useful for me.  Anyhow, I've had this use of <fn> for 15
years now, and 15 years ago there was nothing like frames in the desktop
file.

> Maybe this stuff you do is the culprit?

I don't really think so.  It's been working for a decade and a half.  I
think it more likely that Juanma didn't see any need to preserve the
association of particular frames with particular buffers when extending
desktop to handle frames.  Indeed the notion of "particular frames" is,
so far, probably idiosyncratic to me, rather than to Emacs.  But it would
be nice if desktop could preserve the ordering of the frames and buffers,
too.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii]

> Date: Sun, 22 Jan 2017 19:38:41 +0000
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I always have several frames in my sessions, each one with its buffer,
> > and when I restore the sessions, each frame comes up with the same
> > buffer it had when I shut down Emacs, no complicated frame-walking
> > dance necessary, neither before shutting down Emacs nor after
> > restarting it.
> 
> Something similar happens when I use the defaults.  But the buffers come
> up in the "wrong" frames (i.e. associated with a different <fn> key),
> making it not useful for me.

Then perhaps the problem is that the frame names are jumbled after
restoring them, something that "normal" usage will never reveal, as
most people don't care about the internal numbering of frames, and I
don't think there was a requirement to keep them when restoring.

Re: GUI vs TTY when saving & restoring framesets

[Alan Mackenzie]

Hello, Eli.

On Sun, Jan 22, 2017 at 22:03:57 +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Jan 2017 19:38:41 +0000
> > Cc: lekktu@gmail.com, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I always have several frames in my sessions, each one with its buffer,
> > > and when I restore the sessions, each frame comes up with the same
> > > buffer it had when I shut down Emacs, no complicated frame-walking
> > > dance necessary, neither before shutting down Emacs nor after
> > > restarting it.

> > Something similar happens when I use the defaults.  But the buffers come
> > up in the "wrong" frames (i.e. associated with a different <fn> key),
> > making it not useful for me.

> Then perhaps the problem is that the frame names are jumbled after
> restoring them, something that "normal" usage will never reveal, as
> most people don't care about the internal numbering of frames, and I
> don't think there was a requirement to keep them when restoring.

The order of the frames returned by frame-list is not defined in its doc
string or the Elisp manual.  Maybe it should be.  It appears to be in
reverse order of creation, presumably because the frame creation
routine simply pushes each new frame onto the front of a list.

Maybe inserting a judicious nreverse into the frame group code would get
me part of what I want.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: GUI vs TTY when saving & restoring framesets

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Sun, Jan 22, 2017 at 8:38 PM, Alan Mackenzie <acm@muc.de> wrote:

> Something similar happens when I use the defaults.  But the buffers come
> up in the "wrong" frames (i.e. associated with a different <fn> key),
> making it not useful for me.  Anyhow, I've had this use of <fn> for 15
> years now, and 15 years ago there was nothing like frames in the desktop
> file.

Well, frameset restoration is a new feature, which does not interfere with
what you did before. It just does not do what you want in a new situation
(you could always set desktop-restore-frames to nil and not lose any old
functionality). I don't mean that your use case is not valid or relevant,
only that it is hardly surprising that it doesn't work out of the box ;-)

> I
> think it more likely that Juanma didn't see any need to preserve the
> association of particular frames with particular buffers when extending
> desktop to handle frames.

I tried to preserve anything that I could imagine being even remotely
useful, or being told so. Obviously, there's room for improvement.

> But it would
> be nice if desktop could preserve the ordering of the frames and buffers,
> too.

I'll look into it.

[-- Attachment #2: Type: text/html, Size: 1571 bytes --]

Re: GUI vs TTY when saving & restoring framesets

[Andreas Schwab]

On Jan 22 2017, Alan Mackenzie <acm@muc.de> wrote:

> I care a great deal about it.  I have set up keys <f1> to <f11> in the
> global key map to mean "switch to frame Fn".  Thus, rather than just
> being an arbitrary GUI window, each frame is associated with a particular
> function key.  I even have "Fn" in the mode line to see which frame I'm
> in.

Have you considered giving the frames fixed names?  Then you won't
depend on creation order.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GUI vs TTY when saving & restoring framesets

[martin rudalics]

 > Have you considered giving the frames fixed names?  Then you won't
 > depend on creation order.

If the frame list is reversed by desktop, ‘next-frame’ in the restored
session will work like ‘previous-frame’ in the saved session.

martin

Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii]

> 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

Re: GUI vs TTY when saving & restoring framesets

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Sun, Jan 22, 2017 at 5:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> If you can find a way of fixing 17693 without disabling frameset
> restoration, feel free to do that on master.

I'm going to take a hard look at this and every frameset bug I can find.
I'll revert the frameset.el and desktop.el code (locally, not on the
repository) to its previous state and will try to understand the issues and
the possible fixes. (I'm not implying the current fixes aren't good, only
that I still don't understand their implications).

>  Given user feedback we
> have, I think we should not create GUI frames when Emacs is invoked
> with -nw, though, at least by default.

I don't understand this. Creating GUI frames in a -nw session shouldn't
happen. "Mimicking" the GUI frames in the -nw session is what the code
intended to do, so if you have three frames of whatever size and other
parameters, the TTY session would start with three tty frames (F1 to F3).
Then going back to GUI mode would restore the original GUI frames (not the
tty ones).

> 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

That is exactly what worked before (or, at least, it worked in all my
tests) and it's broken now.

[-- Attachment #2: Type: text/html, Size: 1887 bytes --]

Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 22 Jan 2017 22:15:14 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > Given user feedback we
> > have, I think we should not create GUI frames when Emacs is invoked
> > with -nw, though, at least by default.
> 
> I don't understand this. Creating GUI frames in a -nw session shouldn't happen. "Mimicking" the GUI frames in
> the -nw session is what the code intended to do, so if you have three frames of whatever size and other
> parameters, the TTY session would start with three tty frames (F1 to F3). Then going back to GUI mode would
> restore the original GUI frames (not the tty ones).

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.  I thought
this was a feature, but if you say it's a bug, fixing it will fulfill
user expectations.

> > . emacs
> > . emacs -nw
> > . emacs
> 
> That is exactly what worked before (or, at least, it worked in all my tests) and it's broken now.

Because the original code had worse problems, and we didn't know how
to fix it better than that.

Re: GUI vs TTY when saving & restoring framesets

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On Mon, Jan 23, 2017 at 4:36 AM, Eli Zaretskii <eliz@gnu.org> 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.

[-- Attachment #2: Type: text/html, Size: 2884 bytes --]

Re: GUI vs TTY when saving & restoring framesets

[Eli Zaretskii]

> 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.

Re: GUI vs TTY when saving & restoring framesets

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Mon, Jan 23, 2017 at 4:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> A I've said earlier, if we think different users might want different
> behavior in this respect, we should have a customizable option.

Agreed.

> 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.

Yes. I'm surprised this failed. This is basic stuff.

> 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.

Same here. I never work with -nw except for testing purposes.

> 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.

Depending where we want to go, these features aren't more exotic, just a
generalization of sorts. But I agree with you. Don't want to waste my time
with something that people doesn't need.

> I didn't write the above to assign blame.

I know. But that you don't blame me doesn't mean I don't feel a little
guilty. I've disliked when someone started some big (or user-visible)
change in Emacs and then disappeared (not a very common occurrence, but not
unheard of). And I did the same. Hi pot, meet kettle.

[-- Attachment #2: Type: text/html, Size: 1986 bytes --]

Re: GUI vs TTY when saving & restoring framesets

[Stefan Monnier]

> 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.

I think this is basically the same issue as "multiple X11 servers".
IOW, the issue is how to handle frames on multiple "terminals" (in the
sense of `frame-terminal`).

I believe most users use Emacs in "single terminal" mode with very few
exceptions, and even when they occasionally or often use a single Emacs
session with frames on several terminals, they most likely don't want
the "desktop save&restore" to pay attention to the frames on the
"non-main terminal" because at startup those other terminals often don't
exist or aren't accessible.

There's also an issue of naming: the "main terminal" doesn't need to
have a name (and in 99% of the cases shouldn't have a name: if I save an
Emacs session in an environment where I had DISPLAY=:5, and try to
restore it in an environment where DISPLAY=:4 it should use :4 rather
than :5 to open my frames), whereas the other ones need to be named.

> 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.

Sounds like a good idea.


        Stefan