[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs
From: |
Eli Zaretskii |
Subject: |
bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs |
Date: |
Tue, 26 Apr 2022 21:14:37 +0300 |
> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org, eric@swenson.org, 55070@debbugs.gnu.org
> Date: Tue, 26 Apr 2022 20:40:10 +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.
>
> Because restoring frames on tty fails without this fix.
Restoring frames is desktop.el's business, so it should be fixed
there. Why does "emacs -nw" at all save frame coordinates if they
cannot be restored?
> > 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.
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, (continued)
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Lars Ingebrigtsen, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/26
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs,
Eli Zaretskii <=
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/27
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eric Swenson, 2022/04/27
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/28
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eric Swenson, 2022/04/28
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Juri Linkov, 2022/04/28
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/30
- bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs, Eli Zaretskii, 2022/04/27