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

[Eric Swenson <eric@swenson.org>]

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