[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, 26 Apr 2022 14:26:22 +0300 |
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, Eric Swenson <eric@swenson.org>,
> 55070@debbugs.gnu.org
> Date: Tue, 26 Apr 2022 12:16:25 +0200
>
> Juri Linkov <juri@linkov.net> 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).
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eric Swenson, 2022/04/22
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/23
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Lars Ingebrigtsen, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs,
Eli Zaretskii <=
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/27
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eric Swenson, 2022/04/27
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/28
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eric Swenson, 2022/04/28
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/28
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/30