all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org
Subject: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs
Date: Tue, 03 May 2022 21:28:51 +0300	[thread overview]
Message-ID: <83fslq4gik.fsf@gnu.org> (raw)
In-Reply-To: <86pmkufql3.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 03 May 2022 20:57:52 +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	other threads:[~2022-05-03 18:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22 23:27 bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Eric Swenson
2022-04-23  6:13 ` Eli Zaretskii
2022-04-23 13:52   ` Eric Swenson
2022-04-23 14:25     ` Eli Zaretskii
2022-04-23 14:53       ` Eric Swenson
2022-04-23 15:16         ` Eli Zaretskii
2022-04-23 15:39           ` Eric Swenson
2022-04-26  7:58       ` Juri Linkov
2022-04-26 10:16         ` Lars Ingebrigtsen
2022-04-26 11:26           ` Eli Zaretskii
2022-04-26 15:28           ` Juri Linkov
2022-04-26 16:09             ` Eli Zaretskii
2022-04-26 17:40               ` Juri Linkov
2022-04-26 18:14                 ` Eli Zaretskii
2022-04-27 16:53                   ` Juri Linkov
2022-04-27 17:02                     ` Eric Swenson
2022-04-28  7:01                       ` Juri Linkov
2022-04-28 16:18                         ` Eric Swenson
2022-04-28 17:39                           ` Juri Linkov
2022-04-30  8:42                             ` Eli Zaretskii
2022-05-01 17:25                               ` Juri Linkov
2022-05-03 16:31                                 ` Eli Zaretskii
2022-05-03 17:57                                   ` Juri Linkov
2022-05-03 18:28                                     ` Eli Zaretskii [this message]
2022-05-05 16:35                                       ` Juri Linkov
2022-05-05 16:51                                         ` Eli Zaretskii
2022-05-05 18:08                                           ` Juri Linkov
2022-04-27 17:16                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83fslq4gik.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=55070@debbugs.gnu.org \
    --cc=eric@swenson.org \
    --cc=juri@linkov.net \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.