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

Previous Next

Full log

Message #46 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: Tue, 26 Apr 2022 21:14:37 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org,  eric <at> swenson.org,  55070 <at> debbugs.gnu.org
> Date: Tue, 26 Apr 2022 20:40:10 +0300
> 
> >>   ;; People don't expect emacs -nw, or --daemon,
> >>   ;; to create graphical frames (bug#17693).
> >>   ;; TODO perhaps there should be a separate value
> >>   ;; for desktop-restore-frames to control this startup behavior?
> >>
> >> So this patch creates such separate values:
> >
> > 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.  Why does "emacs -nw" at all save frame coordinates if they
cannot be restored?

> > Or if you do need it, why does it have to look so ad-hoc?  If
> > we want to support in frameset.el frames for which some frame
> > parameters make no sense, let's do that explicitly, not by sweeping
> > problems under the carpet by substituting some arbitrary values for
> > those parameters that give us trouble.
> 
> These values are not arbitrary.  The function frame-monitor-attributes
> used in the same fixed function frameset-move-onscreen returns on tty:
> 
>   ((geometry 0 0 80 23)
>    (workarea 0 0 80 23))
> 
> where 'left' and 'top' values are zero.

That is arbitrary as well.

I hope we can find a more elegant and explicit solution to this issue.

Previous Next

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