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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: eric@swenson.org,  larsi@gnus.org,  55070@debbugs.gnu.org
> Date: Sun, 01 May 2022 20:25:52 +0300
> 
> > Please try the patch below.  Its main idea is that calling
> > frameset-move-onscreen makes no sense on a text-mode display, so I
> > made desktop.el force frameset.el avoid calling that function in this
> > case.  The rest is basically a simple cleanup.
> 
> The patch works without problems (I didn't notice
> the argument :force-onscreen before).
> 
> > In addition to testing the use case of both saving and restoring the
> > desktop in a -nw session, I'd appreciate testing when the desktop was
> > saved in a GUI session and is restored in a TTY session, and vice
> > versa.
> 
> Saving the desktop in a GUI session and restoring in a TTY session
> adds an empty line between the top buffer and the tab bar when
> tab-bar-mode was enabled before saving.

This is a subtle bug in how we compute the tab-bar-lines frame
parameter.  Observe:

 emacs -Q
 M-x tab-bar-mode RET
 M-: (frame-parameter nil 'tab-bar-lines) => 2

Surprise!

The problem is that the tab-bar line is slightly higher than the
canonical line height of the frame, so when we compute the height in
lines, we get 1 more.

I think this means we cannot save and restore tab-bar-mode by relying
on the tab-bar-lines frame parameter; the solution should be in a
special support for desktop.el in tab-bar.el.  For example, remove the
tab-bar-line frame parameter when saving the desktop, and instead save
the tab-bar-mode state; then restoring the desktop would turn on
tab-bar-mode in the restored session, and recreate the tab bar of the
desired height.

I hope you can develop such a solution, so that tab bars could be
meaningfully restored on TTY frames.

Btw, what about tab-bar-show -- should it be saved as well? at least
if its value is not the default?

> Saving the desktop in a TTY session and restoring in a GUI session
> restores only the first frame, but the message says 2 frames were restored.

It did restore 2 frames (try evaluating '(frame-list)' and you will
see).  It's just that all the frames but the first one are invisible,
because the frames restored from TTY-originated desktop have no
'visibility' parameter, so when they are restored on GUI display, that
is interpreted as invisible frames.  I think I fixed that now.

> > Likewise for when the session in which the desktop is restored
> > is a daemon session -- the main concern there is that a daemon session
> > shouldn't restore frames at all.
> 
> I don't use a daemon session, maybe someone could help to test it.

OK, maybe Eric or someone else will.

Anyway, I installed the changes on the master branch.  I think we
should leave this bug open until the tab-bar issue (and any other
issues that might be left) are resolved.

Thanks.