emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI vs TTY when saving & restoring framesets


From: Eli Zaretskii
Subject: Re: GUI vs TTY when saving & restoring framesets
Date: Mon, 23 Jan 2017 17:49:12 +0200

> From: Juanma Barranquero <address@hidden>
> Date: Mon, 23 Jan 2017 15:15:52 +0100
> Cc: Emacs developers <address@hidden>
> 
> > 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 via email to

[Prev in Thread] Current Thread [Next in Thread]