Subject: Re: bug#46299: 28.0.50; Value of tab-bar-show not respected in new frames.

From: martin rudalics <[email-masked]>
Date: Tue, 9 Feb 2021 09:58:39 +0100

> I'll do my best to update the docstring. Note that I do not contribute
 > to emacs often, nor do I regularly code in elisp, so I'm not familiar
 > with the conventions and you are encouraged to modify my changes as
 > you see fit.

Don't worry.  These "-lines" frame parameters are a minefield - we just
should try to clarify things the best possible way while you're working
on it.

 > (defun tab-bar--tab-bar-lines-for-frame (frame)
 > -  "Compute the correct value of tab-bar-lines for the given frame."
 > +  "Compute the correct value of tab-bar-lines for FRAME."

But what "is" the correct value and why and how would we want to
"compute" it?

 > As far as I understand, tab-bar-lines is always just 1 or 0, meaning
 > whether to show the tab-bar at all or not. Maybe it would be better to
 > just rename the parameter? I guess if that is done then it does not
 > necessarily need further explanation in docstrings.

That ship has sailed long ago.  Neither the 'menu-bar-lines' nor the
'tool-bar-lines' parameters convey useful information in this regard and
'tab-bar-lines' just follows suit.  Their only practical (and completely
misguided IMHO) purpose is to show the corresponding bar by setting the
parameter to a non-zero value and remove it by setting the parameter to
zero.

Sometimes, as with our native tool bars, their value gives the number of
frame lines occupied by the bar.  And very occasionally setting the
parameter to a non-zero value can have strange effects: On a non-toolkit
build setting menu-bar-lines to 7 will show six blank lines below a
one-line menu bar which does not wrap anyway.

In either case, we can hardly change the names of these frame parameters
because they probably appear in too many applications and init files out
there.  We could state somewhere that these are, in fact, booleans and
should be set and interpreted in that sense.  Even that is not entirely
trivial.

martin