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

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Bastian Beranek <bastian.beischer <at> gmail.com>
Cc: 46299 <at> debbugs.gnu.org
Subject: Re: bug#46299: 28.0.50; Value of tab-bar-show not respected in new
 frames.
Date: Mon, 15 Feb 2021 19:01:17 +0200

>> Before your patch, I did nothing with the enabled tab-bar,
>> but now it disables the tab-bar, and doesn't enable it again later,
>> because tab-bar-show is let-bound to nil.
>
> Could you please describe the desired behavior of tab-switcher in a few
> more words? I can't see anything wrong with it if I try it out here,

Sorry, this failed in one of the previous versions of the patch,
but works fine in the last version of your patch pushed to master.
So there is no problem, sorry for false alarm.

> although I can sort of see what you're getting at: While the
> tab-swicher is active there should be no tab bar, and it should return
> when it is finished?

Maybe this could provide a nice visual effect, but the problem
is that it's not easy to detect the moment when it is finished.

I often use tab-switcher to create a new tab, and sometimes instead
of selecting an existing tab from the tab list, I change the mind
and switch to another buffer in the same new tab.

> What I see is that the tab-bar just stays on all the time, with a
> temporary tab for the tab-switcher itself. I have tab-bar-show
> customized to "1" here.

This is fine.

> Side question: Why does tab-switcher need to create a tab for its
> purpose? Doesn't it make more sense to use a regular buffer for that?

This is to emulate window switching feature that exists on most window managers:
all windows are unselected when the window switcher is activated.

>> A good solution would be to add a new choice value to tab-bar-show.
>> Something like 'do-not-change-tab-bar-lines', but shorter.
>> Then when let-bound, it should do nothing with the tab-bar-lines.
>
> Wouldn't it make more sense to have a different variable for that?
> Because tab-bar-show is a defcustom and we wouldn't want to expose this
> special value to users, right?

Exposing such value to users is fine, but anyway it seems there is
no need to add a new value or variable.

>> Also this is related to another problem:
>> What if the user wants to manually enable the tab bar on one frame only
>> without enabling tab-bar-mode?  Currently it's possible with
>>
>>   (add-hook 'after-make-frame-functions 'toggle-frame-tab-bar)
>>
>> But tab-bar--update-tab-bar-lines will disable it sooner or later.
>> Customizing to the same value like 'do-not-change-tab-bar-lines'
>> will solve this problem as well.
>
> That's true. I can see how tab-bar--update-tab-bar-lines can interfere
> with toggle-frame-tab-bar.
>
> But I think we would need a frame dependent variable to fix this. We
> can't use a global single variable, because toggle-frame-tab-bar is not
> supposed to change the behavior of tabs on other frames. I have to think
> about a good solution for a bit longer. Is attaching a new parameter to
> frames similiar to this a possibility?

Good idea.  Actually frame parameters could serve as a kind of
"frame-local variables".

> Note that I'm not yet suggesting that we do it exactly as the above,
> this has other issues - toggling twice does leave the do-not-change
> frame parameter in place for example, so it's not the same as doing
> nothing.

Also toggling once should handle two cases:

1. while tab-bar-lines is enabled in all frames, it should disable
   tab-bar-lines in the specified frame;

2. while tab-bar-lines is disabled in all frames, it should enable
   tab-bar-lines in the specified frame.

Previous Next

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