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

[Juri Linkov]

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

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

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

Adding a comment to the source code will help.