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

Previous Next

Full log

Message #40 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 19:09:21 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Eric Swenson <eric <at> swenson.org>,
>   55070 <at> debbugs.gnu.org
> Date: Tue, 26 Apr 2022 18:28:18 +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.  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.

IOW, in 10 years, would you be able to remember and explain why we use
zero instead of 'left' and 'top'?

Previous Next

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