[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs
From: |
Eli Zaretskii |
Subject: |
bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs |
Date: |
Tue, 03 May 2022 19:31:01 +0300 |
> 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.