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

Previous Next

Package: emacs;

Reported by: Eric Swenson <eric <at> swenson.org>

Date: Sat, 23 Apr 2022 00:00:02 UTC

Severity: normal

Tags: moreinfo, patch

Found in version 28.1

Fixed in version 29.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
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 19:53:43 +0300
tags 55070 + patch
quit

>> >>   ;; 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.

The sole purpose of frameset.el is to save and restore frames.
So the bug was fixed in frameset.el.

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

"emacs -nw" doesn't save frame coordinates.

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

I provided the patch to fix this bug.
If you know how to fix it better, this would be fine.




This bug report was last modified 3 years and 72 days ago.

Previous Next


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