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

Previous Next

Full log

View this message in rfc822 format

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

Did you provide another patch, Juri?  Or is it the same one you provided yesterday in this thread?  -- Eric

On 4/27/22, 9:57 AM, "Juri Linkov" <juri <at> linkov.net> wrote:

    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.

Previous Next

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