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

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

[Eric Swenson]

[-- Attachment #1: Type: text/plain, Size: 5055 bytes --]

I've tried the following in versions 26.3, 27.1, and 28.1.  If you use

desktop-save in a non-GUI (-nw) run of emacs, with no init.el loaded

(-Q), and then exit emacs, upon reentry, while the files that were

loaded in buffers at the time of the save are present, the windows are

not restored properly. Only one window is correct -- and only one window

is present.  If you start emacs without the "-nw" option, however,

everything works just fine.

 

For some of us who SSH into servers, we have no option but to use the

non-GUI version of emacs.

 

Note, I started this ticket in an emacs invocation with "-nw" but

without specifying "-Q", so my minimal, test init.el was executed. It appears

below:

 

  (desktop-save-mode 1)

  (setq desktop-load-locked-desktop nil)

  (desktop-read)

 

This bug report was issued from Ubuntu 20.04.  However, I can see the

exact same behavior on macOS as well.

 

-- Eric

 

In GNU Emacs 28.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)

 of 2022-04-06 built on lcy02-amd64-033

Repository revision: 8b4be592de49fddc996ebb3e544256e20c81cf85

Repository branch: master

System Description: Ubuntu 20.04.4 LTS

 

Configured using:

 'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3

 --without-xaw3d --with-modules --with-cairo --with-native-compilation

 'CFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include

 -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu

 -O2' 'CPPFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include

 -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu'

 'LDFLAGS=-L/build/emacs/parts/emacs/install/lib

 -L/build/emacs/parts/emacs/install/usr/lib

 -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu

 -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu''

 

Configured features:

ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG

JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES

NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF

TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

 

Important settings:

  value of $LANG: en_US.UTF-8

  value of $XMODIFIERS: @im=ibus

  locale-coding-system: utf-8-unix

 

Major mode: Shell-script

 

Minor modes in effect:

  sh-electric-here-document-mode: t

  desktop-save-mode: t

  tooltip-mode: t

  global-eldoc-mode: t

  show-paren-mode: t

  electric-indent-mode: t

  mouse-wheel-mode: t

  tool-bar-mode: t

  menu-bar-mode: t

  file-name-shadow-mode: t

  global-font-lock-mode: t

  font-lock-mode: t

  blink-cursor-mode: t

  auto-composition-mode: t

  auto-encryption-mode: t

  auto-compression-mode: t

  line-number-mode: t

  indent-tabs-mode: t

  transient-mark-mode: t

 

Load-path shadows:

None found.

 

Features:

(shadow sort mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa

derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs

auth-source eieio eieio-core eieio-loaddefs password-cache json map

text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231

mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums

mm-util mail-prsvr mail-utils mule-util term/xterm xterm dired-aux dired

dired-loaddefs time-date sh-script smie executable comp comp-cstr

warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv

bytecomp byte-compile cconv desktop frameset cl-loaddefs cl-lib

site-start iso-transl tooltip eldoc paren electric uniquify ediff-hook

vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win

term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe

tabulated-list replace newcomment text-mode lisp-mode prog-mode register

page tab-bar menu-bar rfn-eshadow isearch easymenu timer select

scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors

frame minibuffer cl-generic cham georgian utf-8-lang misc-lang

vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932

hebrew greek romanian slovak czech european ethiopic indian cyrillic

chinese composite emoji-zwj charscript charprop case-table epa-hook

jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button

loaddefs faces cus-face macroexp files window text-properties overlay

sha1 md5 base64 format env code-pages mule custom widget

hashtable-print-readable backquote threads dbusbind inotify lcms2

dynamic-setting system-font-setting font-render-setting cairo

move-toolbar gtk x-toolkit x multi-tty make-network-process

native-compile emacs)

 

Memory information:

((conses 16 101029 8397)

 (symbols 48 8635 1)

 (strings 32 24989 3159)

 (string-bytes 1 873580)

 (vectors 16 16905)

 (vector-slots 8 309235 14578)

 (floats 8 31 41)

 (intervals 56 574 0)

 (buffers 992 17))


[-- Attachment #2: Type: text/html, Size: 14249 bytes --]

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

[Eli Zaretskii]

> Date: Fri, 22 Apr 2022 16:27:47 -0700
> From: Eric Swenson <eric@swenson.org>
> Cc: "Eric Swenson via groups.io" <eric=swenson.org@groups.io>
> 
> I've tried the following in versions 26.3, 27.1, and 28.1.  If you use
> desktop-save in a non-GUI (-nw) run of emacs, with no init.el loaded
> (-Q), and then exit emacs, upon reentry, while the files that were
> loaded in buffers at the time of the save are present, the windows are
> not restored properly. Only one window is correct -- and only one window
> is present.  If you start emacs without the "-nw" option, however,
> everything works just fine.
>  
> For some of us who SSH into servers, we have no option but to use the
> non-GUI version of emacs.
> 
> Note, I started this ticket in an emacs invocation with "-nw" but
> without specifying "-Q", so my minimal, test init.el was executed. It appears
> below:
>  
>   (desktop-save-mode 1)
>   (setq desktop-load-locked-desktop nil)
>   (desktop-read)

Please tell more about the symptoms:

 . what do you mean by "only one window"? do you mean "frame" or do
   you mean "window"?
 . what does one need to do before exiting the first session to
   observe the results in the next one? for example, if you indeed
   mean "only one window", then I guess in the first session one needs
   to do something like "C-x 2" or maybe "C-x 4 f SOME-FILE"? please
   describe those actions.
 . is the second session also a -nw session or is it a GUI session?

Thanks.

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

[Eric Swenson]

I start emacs with a single frame. I create three windows by doing, for example, C-x 2, and C-x 3. In each window, I read in a file. Then I invoke M-x desktop-save, and select a directory. I always use ~/.emacs.d.  Then I exit emacs with C-x C-c.

Then I renter emacs and invoke C-x desktop-load.

If for both sessions, I invoke emacs with “-Q” only, on either macOS or Linux with Gnome desktop, everything works fine. However, if I invoke emacs with “-nw -Q”, when I run M-x desktop-load, I only get a single window with one of the files loaded. The other two files are loaded into buffers, but their windows were not restored.

I haven’t tried a case where I ran a GUI session first and saved the desktop and then ran the non-GUI (-nw) session for the restore, but I’m pretty sure it would also fail. 

I think the “issue” is that desktop-load doesn’t work in the -nw session.

And yes, you can set up the windows using C-x 4 f <filename> as well as the explicitly creating a second window and splitting and then loading files into each. It doesn’t really matter. 

-- Eric (KN6SIJ)


> On Apr 22, 2022, at 23:13, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
>> 
>> Date: Fri, 22 Apr 2022 16:27:47 -0700
>> From: Eric Swenson <eric@swenson.org>
>> Cc: "Eric Swenson via groups.io" <eric=swenson.org@groups.io>
>> 
>> I've tried the following in versions 26.3, 27.1, and 28.1.  If you use
>> desktop-save in a non-GUI (-nw) run of emacs, with no init.el loaded
>> (-Q), and then exit emacs, upon reentry, while the files that were
>> loaded in buffers at the time of the save are present, the windows are
>> not restored properly. Only one window is correct -- and only one window
>> is present.  If you start emacs without the "-nw" option, however,
>> everything works just fine.
>> 
>> For some of us who SSH into servers, we have no option but to use the
>> non-GUI version of emacs.
>> 
>> Note, I started this ticket in an emacs invocation with "-nw" but
>> without specifying "-Q", so my minimal, test init.el was executed. It appears
>> below:
>> 
>>  (desktop-save-mode 1)
>>  (setq desktop-load-locked-desktop nil)
>>  (desktop-read)
> 
> Please tell more about the symptoms:
> 
> . what do you mean by "only one window"? do you mean "frame" or do
>   you mean "window"?
> . what does one need to do before exiting the first session to
>   observe the results in the next one? for example, if you indeed
>   mean "only one window", then I guess in the first session one needs
>   to do something like "C-x 2" or maybe "C-x 4 f SOME-FILE"? please
>   describe those actions.
> . is the second session also a -nw session or is it a GUI session?
> 
> Thanks.

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

[Eli Zaretskii]

> From: Eric Swenson <eric@swenson.org>
> Date: Sat, 23 Apr 2022 06:52:13 -0700
> Cc: 55070@debbugs.gnu.org, eric=swenson.org@groups.io
> 
> I start emacs with a single frame. I create three windows by doing, for example, C-x 2, and C-x 3. In each window, I read in a file. Then I invoke M-x desktop-save, and select a directory. I always use ~/.emacs.d.  Then I exit emacs with C-x C-c.
> 
> Then I renter emacs and invoke C-x desktop-load.
> 
> If for both sessions, I invoke emacs with “-Q” only, on either macOS or Linux with Gnome desktop, everything works fine. However, if I invoke emacs with “-nw -Q”, when I run M-x desktop-load, I only get a single window with one of the files loaded. The other two files are loaded into buffers, but their windows were not restored.
> 
> I haven’t tried a case where I ran a GUI session first and saved the desktop and then ran the non-GUI (-nw) session for the restore, but I’m pretty sure it would also fail. 
> 
> I think the “issue” is that desktop-load doesn’t work in the -nw session.
> 
> And yes, you can set up the windows using C-x 4 f <filename> as well as the explicitly creating a second window and splitting and then loading files into each. It doesn’t really matter. 

OK, thanks for the details.  They tell me that what you see is the
intended behavior: desktop.el doesn't restore frames and windows on
text-mode terminals.  This is because restoring frames and windows in
a -nw session is problematic, especially if the desktop was saved from
a GUI session.

If this causes a lot of inconvenience, maybe we could have a user
option to allow restoring the frameset in -nw session, for those who
only ever use -nw sessions.  But we cannot allow that in general, and
not by default, IMO.

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

[Eric Swenson]

Thanks. It seems really strange that this should be problematic in -nw sessions. I could understand not being able to restore windows between a GUI and -nw sessions, but I don’t see why, since windows work perfectly well in a single frame in a -nw session that restoring them should be problematic.

Can you explain why this is difficult? In -nw sessions the same commands split windows perfectly well. So clearly -nw sessions support window splitting — why not restoring? (I think a restriction that requires the saving and restoring sessions to be the same kind (either both -nw or both GUI) is a perfectly sensible restriction.

-- Eric (KN6SIJ)


> On Apr 23, 2022, at 07:25, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
>> 
>> From: Eric Swenson <eric@swenson.org>
>> Date: Sat, 23 Apr 2022 06:52:13 -0700
>> Cc: 55070@debbugs.gnu.org, eric=swenson.org@groups.io
>> 
>> I start emacs with a single frame. I create three windows by doing, for example, C-x 2, and C-x 3. In each window, I read in a file. Then I invoke M-x desktop-save, and select a directory. I always use ~/.emacs.d.  Then I exit emacs with C-x C-c.
>> 
>> Then I renter emacs and invoke C-x desktop-load.
>> 
>> If for both sessions, I invoke emacs with “-Q” only, on either macOS or Linux with Gnome desktop, everything works fine. However, if I invoke emacs with “-nw -Q”, when I run M-x desktop-load, I only get a single window with one of the files loaded. The other two files are loaded into buffers, but their windows were not restored.
>> 
>> I haven’t tried a case where I ran a GUI session first and saved the desktop and then ran the non-GUI (-nw) session for the restore, but I’m pretty sure it would also fail. 
>> 
>> I think the “issue” is that desktop-load doesn’t work in the -nw session.
>> 
>> And yes, you can set up the windows using C-x 4 f <filename> as well as the explicitly creating a second window and splitting and then loading files into each. It doesn’t really matter. 
> 
> OK, thanks for the details.  They tell me that what you see is the
> intended behavior: desktop.el doesn't restore frames and windows on
> text-mode terminals.  This is because restoring frames and windows in
> a -nw session is problematic, especially if the desktop was saved from
> a GUI session.
> 
> If this causes a lot of inconvenience, maybe we could have a user
> option to allow restoring the frameset in -nw session, for those who
> only ever use -nw sessions.  But we cannot allow that in general, and
> not by default, IMO.

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

[Eli Zaretskii]

> From: Eric Swenson <eric@swenson.org>
> Date: Sat, 23 Apr 2022 07:53:43 -0700
> Cc: 55070@debbugs.gnu.org
> 
> Thanks. It seems really strange that this should be problematic in -nw sessions. I could understand not being able to restore windows between a GUI and -nw sessions, but I don’t see why, since windows work perfectly well in a single frame in a -nw session that restoring them should be problematic.
> 
> Can you explain why this is difficult? In -nw sessions the same commands split windows perfectly well. So clearly -nw sessions support window splitting — why not restoring? (I think a restriction that requires the saving and restoring sessions to be the same kind (either both -nw or both GUI) is a perfectly sensible restriction.

Emacs currently cannot restore windows without also restoring the
frames.  Technically, this is because we use the frameset.el package
as infrastructure for this desktop.el facility.  And restoring frames
in a -nw session will create GUI frames, something the user didn't
intend.  So we disabled that.

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

[Eric Swenson]

Ah, that makes sense. Thanks. Still, this is very non-obvious to the user and is really an current implementation decision issue rather than a good reason for not supporting it.

I suggest two action items. 1) update the documentation for desktop-save and desktop-read to say that it only works in non -nw sessions. 2) keep this ticket open since the functionality makes as much sense in -nw sessions as in GUI sessions. 

The code could certainly be updated to handle the case where there is a single frame and the user is trying to restore in an -nw session. 

Also, while I have your ear, the obvious command for restoring a desktop when desktop-save is used to save it would be desktop-restore. Desktop-read is very non-intuitive.

Thanks for listening and explaining the reason for the limitation.

-- Eric (KN6SIJ)


> On Apr 23, 2022, at 08:16, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
>> 
>> From: Eric Swenson <eric@swenson.org>
>> Date: Sat, 23 Apr 2022 07:53:43 -0700
>> Cc: 55070@debbugs.gnu.org
>> 
>> Thanks. It seems really strange that this should be problematic in -nw sessions. I could understand not being able to restore windows between a GUI and -nw sessions, but I don’t see why, since windows work perfectly well in a single frame in a -nw session that restoring them should be problematic.
>> 
>> Can you explain why this is difficult? In -nw sessions the same commands split windows perfectly well. So clearly -nw sessions support window splitting — why not restoring? (I think a restriction that requires the saving and restoring sessions to be the same kind (either both -nw or both GUI) is a perfectly sensible restriction.
> 
> Emacs currently cannot restore windows without also restoring the
> frames.  Technically, this is because we use the frameset.el package
> as infrastructure for this desktop.el facility.  And restoring frames
> in a -nw session will create GUI frames, something the user didn't
> intend.  So we disabled that.

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

[Juri Linkov]

> OK, thanks for the details.  They tell me that what you see is the
> intended behavior: desktop.el doesn't restore frames and windows on
> text-mode terminals.  This is because restoring frames and windows in
> a -nw session is problematic, especially if the desktop was saved from
> a GUI session.

Interesting, I see this is disabled explicitly by display-graphic-p in:

  (defun desktop-restoring-frameset-p ()
    "True if calling `desktop-restore-frameset' will actually restore it."
    (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))

When I tried to remove display-graphic-p, then it's problematic indeed
and fails with:

  frameset-move-onscreen(#<frame F1 0x5645998d8be0> t)
  frameset--restore-frame(((minibuffer . t) (tty-type . "xterm-256color") ...
  frameset-restore([frameset 1 ...
  desktop-restore-frameset()
  desktop-read(nil (4))
  funcall-interactively(desktop-read nil (4))
  command-execute(desktop-read record)

So the problem is in frameset-move-onscreen.  A little debugging
revealed that it fails on the nil frame-parameter 'left',
so a small patch could fix it, then restoring frames
in a -nw session works fine:

diff --git a/lisp/frameset.el b/lisp/frameset.el
index 05884eed3a..32966376d8 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -883,8 +883,8 @@ frameset-move-onscreen
   (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-attributes frame)))
 	       (right (+ left width -1))
 	       (bottom (+ top height -1))
-	       (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right))
-	       (fr-top (frameset-compute-pos (frame-parameter frame 'top) top bottom))
+	       (fr-left (frameset-compute-pos (or (frame-parameter frame 'left) 0) left right))
+	       (fr-top (frameset-compute-pos (or (frame-parameter frame 'top) 0) top bottom))
 	       (ch-width (frame-char-width frame))
 	       (ch-height (frame-char-height frame))
 	       (fr-width (max (frame-pixel-width frame) (* ch-width (frame-width frame))))

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> So the problem is in frameset-move-onscreen.  A little debugging
> revealed that it fails on the nil frame-parameter 'left',
> so a small patch could fix it, then restoring frames
> in a -nw session works fine:

I think the reason for disabling restoring frames on -nw wasn't because
of technical reasons, but because of most users not being aware that an
-nw Emacs can have frames, so they ended up with very confusing setups
after restoring from desktop.

But this is an issue that's come up again and again, so I think we
should introduce a new user option to allow desktop to restore frames on
-nw.  (And that means that we should also apply your patch, I think?)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Eric Swenson <eric@swenson.org>,
>   55070@debbugs.gnu.org
> Date: Tue, 26 Apr 2022 12:16:25 +0200
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > So the problem is in frameset-move-onscreen.  A little debugging
> > revealed that it fails on the nil frame-parameter 'left',
> > so a small patch could fix it, then restoring frames
> > in a -nw session works fine:
> 
> I think the reason for disabling restoring frames on -nw wasn't because
> of technical reasons, but because of most users not being aware that an
> -nw Emacs can have frames, so they ended up with very confusing setups
> after restoring from desktop.
> 
> But this is an issue that's come up again and again, so I think we
> should introduce a new user option to allow desktop to restore frames on
> -nw.

I agree.  I think a useful first step could be to teach frameset to
restore windows, but not frames, in some useful way (e.g., restore the
window configuration of just a single frame).

Alternatively, we could try teaching desktop.el to better filter the
frame parameters so that it could ignore the problematic ones, but I
think this will be harder and less reliable.

> (And that means that we should also apply your patch, I think?)

I wouldn't.  It looks too ad-hoc to me, and its only purpose is to fix
desktop.el, so why does it need to be in frameset.el?

The display-graphic-p condition was introduced because we had bug
reports about the previous behavior (which didn't disallow restoring
framesets in -nw sessions).

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

> I think the reason for disabling restoring frames on -nw wasn't because
> of technical reasons, but because of most users not being aware that an
> -nw Emacs can have frames, so they ended up with very confusing setups
> after restoring from desktop.
>
> But this is an issue that's come up again and again, so I think we
> should introduce a new user option to allow desktop to restore frames on
> -nw.  (And that means that we should also apply your patch, I think?)

Indeed, this is what an old comment in desktop.el used to say:

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: desktop-restore-frames.patch --]
[-- Type: text/x-diff, Size: 2113 bytes --]

diff --git a/lisp/desktop.el b/lisp/desktop.el
index cd581e028b..b46c41e0e4 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -412,7 +412,10 @@ desktop-restore-frames
   "When non-nil, save and restore the frame and window configuration.
 See related options `desktop-restore-reuses-frames',
 `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'."
-  :type 'boolean
+  :type '(choice (const :tag "Don't restore frames" nil)
+                 (const :tag "Restore frames" t)
+                 (const :tag "Restore only graphical frames" x)
+                 (const :tag "Restore only -nw frames" tty))
   :group 'desktop
   :version "24.4")
 
@@ -1245,7 +1248,13 @@ desktop-lazy-timer
 ;; ----------------------------------------------------------------------------
 (defun desktop-restoring-frameset-p ()
   "True if calling `desktop-restore-frameset' will actually restore it."
-  (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
+  (and (pcase desktop-restore-frames
+         ('x (display-graphic-p))
+         ('tty (not (display-graphic-p)))
+         ('nil nil)
+         (_ t))
+       desktop-saved-frameset
+       t))
 
 (defun desktop-restore-frameset ()
   "Restore the state of a set of frames.
diff --git a/lisp/frameset.el b/lisp/frameset.el
index 05884eed3a..32966376d8 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -883,8 +883,8 @@ frameset-move-onscreen
   (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-attributes frame)))
 	       (right (+ left width -1))
 	       (bottom (+ top height -1))
-	       (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right))
-	       (fr-top (frameset-compute-pos (frame-parameter frame 'top) top bottom))
+	       (fr-left (frameset-compute-pos (or (frame-parameter frame 'left) 0) left right))
+	       (fr-top (frameset-compute-pos (or (frame-parameter frame 'top) 0) top bottom))
 	       (ch-width (frame-char-width frame))
 	       (ch-height (frame-char-height frame))
 	       (fr-width (max (frame-pixel-width frame) (* ch-width (frame-width frame))))

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Eric Swenson <eric@swenson.org>,
>   55070@debbugs.gnu.org
> Date: Tue, 26 Apr 2022 18:28:18 +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.  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.

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

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.

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

[Eli Zaretskii]

> 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

[Juri Linkov]

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.

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

[Eric Swenson]

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.

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

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

It's the same patch.  Please try it.  Here it's again:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: desktop-restore-frames.patch --]
[-- Type: text/x-diff, Size: 2113 bytes --]

diff --git a/lisp/desktop.el b/lisp/desktop.el
index f41a41c3c3..15cd0bae89 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -412,7 +412,10 @@ desktop-restore-frames
   "When non-nil, save and restore the frame and window configuration.
 See related options `desktop-restore-reuses-frames',
 `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'."
-  :type 'boolean
+  :type '(choice (const :tag "Don't restore frames" nil)
+                 (const :tag "Restore frames" t)
+                 (const :tag "Restore only graphical frames" x)
+                 (const :tag "Restore only -nw frames" tty))
   :group 'desktop
   :version "24.4")
 
@@ -1251,7 +1254,13 @@ desktop-lazy-timer
 ;; ----------------------------------------------------------------------------
 (defun desktop-restoring-frameset-p ()
   "True if calling `desktop-restore-frameset' will actually restore it."
-  (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
+  (and (pcase desktop-restore-frames
+         ('x (display-graphic-p))
+         ('tty (not (display-graphic-p)))
+         ('nil nil)
+         (_ t))
+       desktop-saved-frameset
+       t))
 
 (defun desktop-restore-frameset ()
   "Restore the state of a set of frames.
diff --git a/lisp/frameset.el b/lisp/frameset.el
index 05884eed3a..32966376d8 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -883,8 +883,8 @@ frameset-move-onscreen
   (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-attributes frame)))
 	       (right (+ left width -1))
 	       (bottom (+ top height -1))
-	       (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right))
-	       (fr-top (frameset-compute-pos (frame-parameter frame 'top) top bottom))
+	       (fr-left (frameset-compute-pos (or (frame-parameter frame 'left) 0) left right))
+	       (fr-top (frameset-compute-pos (or (frame-parameter frame 'top) 0) top bottom))
 	       (ch-width (frame-char-width frame))
 	       (ch-height (frame-char-height frame))
 	       (fr-width (max (frame-pixel-width frame) (* ch-width (frame-width frame))))

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

[Eric Swenson]

The patch worked great for me.  I can restore saved sessions in both GUI and -nw mode.  Thanks much. -- Eric

On 4/28/22, 12:09 AM, "Juri Linkov" <juri@linkov.net> wrote:

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

    It's the same patch.  Please try it.  Here it's again:

    diff --git a/lisp/desktop.el b/lisp/desktop.el
    index f41a41c3c3..15cd0bae89 100644
    --- a/lisp/desktop.el
    +++ b/lisp/desktop.el
    @@ -412,7 +412,10 @@ desktop-restore-frames
       "When non-nil, save and restore the frame and window configuration.
     See related options `desktop-restore-reuses-frames',
     `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'."
    -  :type 'boolean
    +  :type '(choice (const :tag "Don't restore frames" nil)
    +                 (const :tag "Restore frames" t)
    +                 (const :tag "Restore only graphical frames" x)
    +                 (const :tag "Restore only -nw frames" tty))
       :group 'desktop
       :version "24.4")

    @@ -1251,7 +1254,13 @@ desktop-lazy-timer
     ;; ----------------------------------------------------------------------------
     (defun desktop-restoring-frameset-p ()
       "True if calling `desktop-restore-frameset' will actually restore it."
    -  (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
    +  (and (pcase desktop-restore-frames
    +         ('x (display-graphic-p))
    +         ('tty (not (display-graphic-p)))
    +         ('nil nil)
    +         (_ t))
    +       desktop-saved-frameset
    +       t))

     (defun desktop-restore-frameset ()
       "Restore the state of a set of frames.
    diff --git a/lisp/frameset.el b/lisp/frameset.el
    index 05884eed3a..32966376d8 100644
    --- a/lisp/frameset.el
    +++ b/lisp/frameset.el
    @@ -883,8 +883,8 @@ frameset-move-onscreen
       (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-attributes frame)))
     	       (right (+ left width -1))
     	       (bottom (+ top height -1))
    -	       (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right))
    -	       (fr-top (frameset-compute-pos (frame-parameter frame 'top) top bottom))
    +	       (fr-left (frameset-compute-pos (or (frame-parameter frame 'left) 0) left right))
    +	       (fr-top (frameset-compute-pos (or (frame-parameter frame 'top) 0) top bottom))
     	       (ch-width (frame-char-width frame))
     	       (ch-height (frame-char-height frame))
     	       (fr-width (max (frame-pixel-width frame) (* ch-width (frame-width frame))))

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

[Juri Linkov]

> The patch worked great for me.  I can restore saved sessions
> in both GUI and -nw mode.  Thanks much.

Thanks for confirming that the patch fixed the bug.
Then let's wait when Eli will finish writing a better patch
that does the same.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  <larsi@gnus.org>,  <55070@debbugs.gnu.org>
> Date: Thu, 28 Apr 2022 20:39:46 +0300
> 
> > The patch worked great for me.  I can restore saved sessions
> > in both GUI and -nw mode.  Thanks much.
> 
> Thanks for confirming that the patch fixed the bug.
> Then let's wait when Eli will finish writing a better patch
> that does the same.

Please try the patch below.  Its main idea is that calling
frameset-move-onscreen makes no sense on a text-mode display, so I
made desktop.el force frameset.el avoid calling that function in this
case.  The rest is basically a simple cleanup.

In addition to testing the use case of both saving and restoring the
desktop in a -nw session, I'd appreciate testing when the desktop was
saved in a GUI session and is restored in a TTY session, and vice
versa.  Likewise for when the session in which the desktop is restored
is a daemon session -- the main concern there is that a daemon session
shouldn't restore frames at all.

Thanks.

diff --git a/lisp/desktop.el b/lisp/desktop.el
index f41a41c..e438b98 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -434,7 +434,9 @@ desktop-restore-forces-onscreen
 Note that checking of frame boundaries is only approximate.
 It can fail to reliably detect frames whose onscreen/offscreen state
 depends on a few pixels, especially near the right / bottom borders
-of the screen."
+of the screen.
+Text-mode frames are always considered onscreen, so this option has
+no effect on restoring frames in a non-GUI session."
   :type '(choice (const :tag "Only fully offscreen frames" t)
 		 (const :tag "Also partially offscreen frames" all)
 		 (const :tag "Do not force frames onscreen" nil))
@@ -1251,7 +1253,11 @@ desktop-lazy-timer
 ;; ----------------------------------------------------------------------------
 (defun desktop-restoring-frameset-p ()
   "True if calling `desktop-restore-frameset' will actually restore it."
-  (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
+  (and desktop-restore-frames desktop-saved-frameset
+       ;; Don't restore frames when the selected frame is the daemon's
+       ;; initial frame.
+       (not (and (daemonp) (not (frame-parameter nil 'client))))
+       t))
 
 (defun desktop-restore-frameset ()
   "Restore the state of a set of frames.
@@ -1262,7 +1268,8 @@ desktop-restore-frameset
 		      :reuse-frames (eq desktop-restore-reuses-frames t)
 		      :cleanup-frames (not (eq desktop-restore-reuses-frames 'keep))
 		      :force-display desktop-restore-in-current-display
-		      :force-onscreen desktop-restore-forces-onscreen)))
+		      :force-onscreen (and desktop-restore-forces-onscreen
+                                           (display-graphic-p)))))
 
 ;; Just to silence the byte compiler.
 ;; Dynamically bound in `desktop-read'.
diff --git a/lisp/frameset.el b/lisp/frameset.el
index 05884ee..c97cef0 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -448,6 +448,7 @@ frameset-session-filter-alist
 (defvar frameset-persistent-filter-alist
   (append
    '((background-color            . frameset-filter-sanitize-color)
+     (bottom                      . frameset-filter-shelve-param)
      (buffer-list                 . :never)
      (buffer-predicate            . :never)
      (buried-buffer-list          . :never)
@@ -464,13 +465,20 @@ frameset-persistent-filter-alist
      (frameset--text-pixel-height . :save)
      (frameset--text-pixel-width  . :save)
      (fullscreen                  . frameset-filter-shelve-param)
+     (GUI:bottom                  . frameset-filter-unshelve-param)
      (GUI:font                    . frameset-filter-unshelve-param)
      (GUI:fullscreen              . frameset-filter-unshelve-param)
      (GUI:height                  . frameset-filter-unshelve-param)
+     (GUI:left                    . frameset-filter-unshelve-param)
+     (GUI:right                   . frameset-filter-unshelve-param)
+     (GUI:top                     . frameset-filter-unshelve-param)
      (GUI:width                   . frameset-filter-unshelve-param)
      (height                      . frameset-filter-shelve-param)
+     (left                        . frameset-filter-shelve-param)
      (parent-frame                . :never)
      (mouse-wheel-frame           . :never)
+     (right                       . frameset-filter-shelve-param)
+     (top                         . frameset-filter-shelve-param)
      (tty                         . frameset-filter-tty-to-GUI)
      (tty-type                    . frameset-filter-tty-to-GUI)
      (width                       . frameset-filter-shelve-param)

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

[Juri Linkov]

> Please try the patch below.  Its main idea is that calling
> frameset-move-onscreen makes no sense on a text-mode display, so I
> made desktop.el force frameset.el avoid calling that function in this
> case.  The rest is basically a simple cleanup.

The patch works without problems (I didn't notice
the argument :force-onscreen before).

> In addition to testing the use case of both saving and restoring the
> desktop in a -nw session, I'd appreciate testing when the desktop was
> saved in a GUI session and is restored in a TTY session, and vice
> versa.

Saving the desktop in a GUI session and restoring in a TTY session
adds an empty line between the top buffer and the tab bar when
tab-bar-mode was enabled before saving.

Saving the desktop in a TTY session and restoring in a GUI session
restores only the first frame, but the message says 2 frames were restored.

> Likewise for when the session in which the desktop is restored
> is a daemon session -- the main concern there is that a daemon session
> shouldn't restore frames at all.

I don't use a daemon session, maybe someone could help to test it.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: eric@swenson.org,  larsi@gnus.org,  55070@debbugs.gnu.org
> Date: Sun, 01 May 2022 20:25:52 +0300
> 
> > Please try the patch below.  Its main idea is that calling
> > frameset-move-onscreen makes no sense on a text-mode display, so I
> > made desktop.el force frameset.el avoid calling that function in this
> > case.  The rest is basically a simple cleanup.
> 
> The patch works without problems (I didn't notice
> the argument :force-onscreen before).
> 
> > In addition to testing the use case of both saving and restoring the
> > desktop in a -nw session, I'd appreciate testing when the desktop was
> > saved in a GUI session and is restored in a TTY session, and vice
> > versa.
> 
> Saving the desktop in a GUI session and restoring in a TTY session
> adds an empty line between the top buffer and the tab bar when
> tab-bar-mode was enabled before saving.

This is a subtle bug in how we compute the tab-bar-lines frame
parameter.  Observe:

 emacs -Q
 M-x tab-bar-mode RET
 M-: (frame-parameter nil 'tab-bar-lines) => 2

Surprise!

The problem is that the tab-bar line is slightly higher than the
canonical line height of the frame, so when we compute the height in
lines, we get 1 more.

I think this means we cannot save and restore tab-bar-mode by relying
on the tab-bar-lines frame parameter; the solution should be in a
special support for desktop.el in tab-bar.el.  For example, remove the
tab-bar-line frame parameter when saving the desktop, and instead save
the tab-bar-mode state; then restoring the desktop would turn on
tab-bar-mode in the restored session, and recreate the tab bar of the
desired height.

I hope you can develop such a solution, so that tab bars could be
meaningfully restored on TTY frames.

Btw, what about tab-bar-show -- should it be saved as well? at least
if its value is not the default?

> Saving the desktop in a TTY session and restoring in a GUI session
> restores only the first frame, but the message says 2 frames were restored.

It did restore 2 frames (try evaluating '(frame-list)' and you will
see).  It's just that all the frames but the first one are invisible,
because the frames restored from TTY-originated desktop have no
'visibility' parameter, so when they are restored on GUI display, that
is interpreted as invisible frames.  I think I fixed that now.

> > Likewise for when the session in which the desktop is restored
> > is a daemon session -- the main concern there is that a daemon session
> > shouldn't restore frames at all.
> 
> I don't use a daemon session, maybe someone could help to test it.

OK, maybe Eric or someone else will.

Anyway, I installed the changes on the master branch.  I think we
should leave this bug open until the tab-bar issue (and any other
issues that might be left) are resolved.

Thanks.

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

[Juri Linkov]

>> Saving the desktop in a GUI session and restoring in a TTY session
>> adds an empty line between the top buffer and the tab bar when
>> tab-bar-mode was enabled before saving.
>
> This is a subtle bug in how we compute the tab-bar-lines frame
> parameter.  Observe:
>
>  emacs -Q
>  M-x tab-bar-mode RET
>  M-: (frame-parameter nil 'tab-bar-lines) => 2
>
> Surprise!
>
> The problem is that the tab-bar line is slightly higher than the
> canonical line height of the frame, so when we compute the height in
> lines, we get 1 more.
>
> I think this means we cannot save and restore tab-bar-mode by relying
> on the tab-bar-lines frame parameter; the solution should be in a
> special support for desktop.el in tab-bar.el.  For example, remove the
> tab-bar-line frame parameter when saving the desktop, and instead save
> the tab-bar-mode state; then restoring the desktop would turn on
> tab-bar-mode in the restored session, and recreate the tab bar of the
> desired height.

Agreed.  Although currently I have no idea how to do this without adding
direct calls of tab-bar.el functions in desktop.el.

> I hope you can develop such a solution, so that tab bars could be
> meaningfully restored on TTY frames.

Such a solution is also needed for GUI frames as well, because
when tab-bar-mode is not enabled explicitly, then after restoring
the desktop with tab-bar-line frame parameters, tab buttons are too ugly.
The graphical versions of these buttons are created only when
tab-bar-mode is enabled on a GUI frame.  So desktop.el should
enable tab-bar-mode somehow.

> Btw, what about tab-bar-show -- should it be saved as well? at least
> if its value is not the default?

tab-bar-lines are updated according to the value of tab-bar-show
in tab-bar--update-tab-bar-lines (called from tab-bar-mode).
So maybe desktop.el should call tab-bar--update-tab-bar-lines too.

But this raises another question: when the user changes the value
of tab-bar-show, should desktop.el show the tab bar exactly as saved,
or should it update the tab bar according to the new value of tab-bar-show
immediately after restoring the desktop?

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: eric@swenson.org,  larsi@gnus.org,  55070@debbugs.gnu.org
> Date: Tue, 03 May 2022 20:57:52 +0300
> 
> > I think this means we cannot save and restore tab-bar-mode by relying
> > on the tab-bar-lines frame parameter; the solution should be in a
> > special support for desktop.el in tab-bar.el.  For example, remove the
> > tab-bar-line frame parameter when saving the desktop, and instead save
> > the tab-bar-mode state; then restoring the desktop would turn on
> > tab-bar-mode in the restored session, and recreate the tab bar of the
> > desired height.
> 
> Agreed.  Although currently I have no idea how to do this without adding
> direct calls of tab-bar.el functions in desktop.el.

It isn't a crime.  It is also not a catastrophe to have in desktop.el
code that knows something about tab-bar.el's code.  We already have
such code in desktop.el that knows something about some minor modes.

> > I hope you can develop such a solution, so that tab bars could be
> > meaningfully restored on TTY frames.
> 
> Such a solution is also needed for GUI frames as well, because
> when tab-bar-mode is not enabled explicitly, then after restoring
> the desktop with tab-bar-line frame parameters, tab buttons are too ugly.
> The graphical versions of these buttons are created only when
> tab-bar-mode is enabled on a GUI frame.  So desktop.el should
> enable tab-bar-mode somehow.

Yes, what I proposed will work for any kind of frame, because
tab-bar-mode calculates the metrics of the tab bar, so doesn't need it
to be already calculated in advance.

> > Btw, what about tab-bar-show -- should it be saved as well? at least
> > if its value is not the default?
> 
> tab-bar-lines are updated according to the value of tab-bar-show
> in tab-bar--update-tab-bar-lines (called from tab-bar-mode).

Yes, but what about future frames?  The use case is: the user restores
a session from desktop file, then proceeds creating new frames with
tab bars of different numbers of tabs.  We'd want tab-bar-show to be
restored from the desktop as well, so that the tab bars on the new
frames behave the same as the user defined in the session that was
restored, no?

> But this raises another question: when the user changes the value
> of tab-bar-show, should desktop.el show the tab bar exactly as saved,
> or should it update the tab bar according to the new value of tab-bar-show
> immediately after restoring the desktop?

I think the idea always was that restoring desktop overrides any local
changes of the saved variables.  Users that want it the other way
around should edit their init files to move the desktop restoration
code before the code which modifies the variables which could be
restored.  I think.

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

>> Agreed.  Although currently I have no idea how to do this without adding
>> direct calls of tab-bar.el functions in desktop.el.
>
> It isn't a crime.  It is also not a catastrophe to have in desktop.el
> code that knows something about tab-bar.el's code.  We already have
> such code in desktop.el that knows something about some minor modes.

So now this is implemented in the attached patch.  The call to
tab-bar-mode takes care about recalculating the correct values
of the tab-bar-line frame parameter.

>> Such a solution is also needed for GUI frames as well, because
>> when tab-bar-mode is not enabled explicitly, then after restoring
>> the desktop with tab-bar-line frame parameters, tab buttons are too ugly.
>> The graphical versions of these buttons are created only when
>> tab-bar-mode is enabled on a GUI frame.  So desktop.el should
>> enable tab-bar-mode somehow.
>
> Yes, what I proposed will work for any kind of frame, because
> tab-bar-mode calculates the metrics of the tab bar, so doesn't need it
> to be already calculated in advance.

The same call to tab-bar-mode also takes care about creating the buttons.

>> tab-bar-lines are updated according to the value of tab-bar-show
>> in tab-bar--update-tab-bar-lines (called from tab-bar-mode).
>
> Yes, but what about future frames?  The use case is: the user restores
> a session from desktop file, then proceeds creating new frames with
> tab bars of different numbers of tabs.  We'd want tab-bar-show to be
> restored from the desktop as well, so that the tab bars on the new
> frames behave the same as the user defined in the session that was
> restored, no?

tab-bar-mode takes care about future frames by adjusting default-frame-alist.

>> But this raises another question: when the user changes the value
>> of tab-bar-show, should desktop.el show the tab bar exactly as saved,
>> or should it update the tab bar according to the new value of tab-bar-show
>> immediately after restoring the desktop?
>
> I think the idea always was that restoring desktop overrides any local
> changes of the saved variables.  Users that want it the other way
> around should edit their init files to move the desktop restoration
> code before the code which modifies the variables which could be
> restored.  I think.

Right, the users can change the order in their init files
to customize this behavior.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: desktop-tab-bar-mode.patch --]
[-- Type: text/x-diff, Size: 762 bytes --]

diff --git a/lisp/desktop.el b/lisp/desktop.el
index e438b98c0e..0f1e3f289a 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -1269,7 +1269,12 @@ desktop-restore-frameset
 		      :cleanup-frames (not (eq desktop-restore-reuses-frames 'keep))
 		      :force-display desktop-restore-in-current-display
 		      :force-onscreen (and desktop-restore-forces-onscreen
-                                           (display-graphic-p)))))
+                                           (display-graphic-p)))
+    (when (seq-some
+           (lambda (frame)
+             (menu-bar-positive-p (frame-parameter frame 'tab-bar-lines)))
+           (frame-list))
+      (tab-bar-mode 1))))
 
 ;; Just to silence the byte compiler.
 ;; Dynamically bound in `desktop-read'.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: eric@swenson.org,  larsi@gnus.org,  55070@debbugs.gnu.org
> Date: Thu, 05 May 2022 19:35:06 +0300
> 
> >> Agreed.  Although currently I have no idea how to do this without adding
> >> direct calls of tab-bar.el functions in desktop.el.
> >
> > It isn't a crime.  It is also not a catastrophe to have in desktop.el
> > code that knows something about tab-bar.el's code.  We already have
> > such code in desktop.el that knows something about some minor modes.
> 
> So now this is implemented in the attached patch.  The call to
> tab-bar-mode takes care about recalculating the correct values
> of the tab-bar-line frame parameter.

Thanks, it LGTM, but please explain in a comment to that code why this
has to be done when restoring frames.

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

[Juri Linkov]

close 55070 29.0.50
thanks

>> So now this is implemented in the attached patch.  The call to
>> tab-bar-mode takes care about recalculating the correct values
>> of the tab-bar-line frame parameter.
>
> Thanks, it LGTM, but please explain in a comment to that code why this
> has to be done when restoring frames.

Done.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  eric@swenson.org,  55070@debbugs.gnu.org
> Date: Wed, 27 Apr 2022 19:53:43 +0300
> 
> >> > 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.

If you want to teach frameset.el to deal with TTY frames, the patch
should explicitly test for TTY frames _inside_ frameset.el.  The way
you proposed to fix it will do the same on GUI frames, where this
situation _should_ signal an error.

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

Then the fix you proposed cannot help the OP, AFAIU, because his use
case was to always use -nw sessions.

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

I suggested a way to fix it.  I'm not saying my suggestion is the only
possible solution, but it's IMO better than what you proposed in at
least one aspect.