Subject: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs

From: Eli Zaretskii <[email-masked]>
Date: Tue, 26 Apr 2022 14:26:22 +0300

> From: Lars Ingebrigtsen <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  Eric Swenson <[email-masked]>,
>   [email-masked]
> Date: Tue, 26 Apr 2022 12:16:25 +0200
> 
> Juri Linkov <[email-masked]> writes:
> 
> > So the problem is in frameset-move-onscreen.  A little debugging
> > revealed that it fails on the nil frame-parameter 'left',
> > so a small patch could fix it, then restoring frames
> > in a -nw session works fine:
> 
> I think the reason for disabling restoring frames on -nw wasn't because
> of technical reasons, but because of most users not being aware that an
> -nw Emacs can have frames, so they ended up with very confusing setups
> after restoring from desktop.
> 
> But this is an issue that's come up again and again, so I think we
> should introduce a new user option to allow desktop to restore frames on
> -nw.

I agree.  I think a useful first step could be to teach frameset to
restore windows, but not frames, in some useful way (e.g., restore the
window configuration of just a single frame).

Alternatively, we could try teaching desktop.el to better filter the
frame parameters so that it could ignore the problematic ones, but I
think this will be harder and less reliable.

> (And that means that we should also apply your patch, I think?)

I wouldn't.  It looks too ad-hoc to me, and its only purpose is to fix
desktop.el, so why does it need to be in frameset.el?

The display-graphic-p condition was introduced because we had bug
reports about the previous behavior (which didn't disallow restoring
framesets in -nw sessions).