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

Previous Next

Full log

Message #57 received at 55070 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: eric <at> swenson.org, 55070 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs
Date: Wed, 27 Apr 2022 20:16:45 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org,  eric <at> swenson.org,  55070 <at> debbugs.gnu.org
> Date: Wed, 27 Apr 2022 19:53:43 +0300
> 
> >> > Thanks, but I don't understand why you need the frameset part of the
> >> > patch.
> >>
> >> Because restoring frames on tty fails without this fix.
> >
> > Restoring frames is desktop.el's business, so it should be fixed
> > there.
> 
> The sole purpose of frameset.el is to save and restore frames.
> So the bug was fixed in frameset.el.

If you want to teach frameset.el to deal with TTY frames, the patch
should explicitly test for TTY frames _inside_ frameset.el.  The way
you proposed to fix it will do the same on GUI frames, where this
situation _should_ signal an error.

> > Why does "emacs -nw" at all save frame coordinates if they
> > cannot be restored?
> 
> "emacs -nw" doesn't save frame coordinates.

Then the fix you proposed cannot help the OP, AFAIU, because his use
case was to always use -nw sessions.

> > I hope we can find a more elegant and explicit solution to this issue.
> 
> I provided the patch to fix this bug.
> If you know how to fix it better, this would be fine.

I suggested a way to fix it.  I'm not saying my suggestion is the only
possible solution, but it's IMO better than what you proposed in at
least one aspect.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.