bug-gnu-emacs
[Top][All Lists]
Advanced

[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, 03 May 2022 21:28:51 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]