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

[Juri Linkov]

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

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