Re: GUI vs TTY when saving & restoring framesets

[Juanma Barranquero <lekktu@gmail.com>]

[-- 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 --]