bug-gnu-emacs
[Top][All Lists]
Advanced

[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).





reply via email to

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