GNU bug report logs - #46299
28.0.50; Value of tab-bar-show not respected in new frames.

Previous Next

Full log

Message #83 received at 46299 <at> debbugs.gnu.org (full text, mbox):

From: Bastian Beranek <bastian.beischer <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 46299 <at> debbugs.gnu.org
Subject: Re: bug#46299: 28.0.50;
 Value of tab-bar-show not respected in new frames.
Date: Fri, 12 Feb 2021 11:24:26 +0100

[Message part 1 (text/plain, inline)]

Hey Juri,

On Fri, Feb 12, 2021 at 10:57 AM Juri Linkov <juri <at> linkov.net> wrote:
>
> Hello Bastian,
>
> Everything in your patch v7 is correct now, except one case of
> tab-bar-new-tab-to:
>
> >> Would you agree that here in tab-bar-new-tab-to, the first call of
> >> tab-bar-mode should already do all these calls: tab-bar--update-tab-bar-lines,
> >> tab-bar--load-buttons, tab-bar--define-keys?  So maybe it should be
> >> sufficient just to leave these 2 lines here:
> >>
> >>     (when tab-bar-show
> >>        (tab-bar-mode 1))
>
> I noticed this could be optimized not to call tab-bar-mode again every time
> when tab-bar-mode was already enabled.  Maybe use something like this:
>
>     (when (and (not tab-bar-mode) tab-bar-show)
>       (tab-bar-mode 1))
>

I've adjusted the patch accordingly, but we do need a call to
tab-bar--update-tab-bar-lines whenever a tab is created (because we
need to check if there is more than one tab now, which changes the
display criterion). So I added:

    (when tab-bar-show
      (if (not tab-bar-mode)
          ;; Switch on tab-bar-mode, since a tab was created
          ;; Note: This also updates tab-bar-lines
          (tab-bar-mode 1)
        (tab-bar--update-tab-bar-lines)))


> > Yes I agree that tab-bar--update-tab-bar-lines is not needed. It
> > happens in the line before when tab-bar-show is not nil and doesn't
> > matter otherwise. I have left these two lines, though:
> >
> >     (when tab-bar-mode
> >       (tab-bar--load-buttons)
> >       (tab-bar--define-keys))
>
> I still have doubts whether these lines are needed at all.
>
> > Because I think defining the keys is useful even if tab-bar-show is
> > nil, so you can switch to another tab using the key bindings even if
> > you can't see the tab-bar.
>
> The problem is that tab-bar--define-keys defines only two keys
> C-TAB and S-C-TAB and [modifier-digit] keys to select a tab by its
> displayed number that mostly make sense with the visible tab bar.
>
> So one of the purposes of the nil value of tab-bar-show was to
> allow the users also to disable the C-TAB and digit keys.  Then
> users could use C-TAB bindings from other packages, while still
> using global tab-switching keys such as 'C-x t o', and also to
> select tabs by names using 'C-x t b', whereas selecting by numbers
> makes sense only when the tab bar is visible.
>
> > As for the buttons, I think it makes sense to load them so that in
> > case tab-bar-show is customized to another value afterwards they are
> > available directly.
>
> tab-bar--load-buttons and tab-bar--define-keys are called anyway
> when enabling the tab bar with tab-bar-mode.  So these two functions
> could be called only in tab-bar-mode, but afterwards when
> it's already enabled, there is no need to call them again.

I see now that you are right and I removed those lines.

Cheers
Bastian

[tab-bar_v8.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.