bug#39649: 27.0.60; tab-line doesn't scroll

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: joca.bt@gmail.com,  39649@debbugs.gnu.org
> Date: Sat, 29 Feb 2020 23:44:56 +0200
> 
> > Why would we need that?  The related display code is in C, so we never
> > needed to expose this to Lisp.
> 
> format-mode-line already exposes it, but fails to properly
> handle its arg FACE.

So you are saying that we already have the API exposed to Lisp, but it
(format-mode-line) doesn't work well?

> >> 6. C-x b test2
> >> 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line))
> >> 8. Note how the the tab-line now uses the face tab-line,
> >>    but this face overrides the faces of individual tabs that
> >>    should have the face tab-line-tab with released-button box style.
> >
> > And here I don't understand what you mean by "overrides".
> 
> Do you see the same button styles with the faces tab-line-tab-inactive and
> tab-line-tab-current as in the case above like they are on the real tab-line?
> These faces are lost when the arg FACE is specified.

I don't think this is a bug, the code behaves as intended.  It's just
that its intent might be not what you expect, and the available
documentation doesn't help to expect what the code does.

The doc string says, inter alia:


  Optional second arg FACE specifies the face property to put on all
  characters for which no face is specified.

But what it really means is that text produced by the various
%-constructs will have FACE if the %-constructs don't provide a face.
In your case, you supply the function with a fixed string, so
specifying FACE overrides the faces you have there, see
store_mode_line_string (which is called in this case with PROPS set to
nil).

At this point let me turn the table and ask why did you need to pass
FACE to format-mode-line in your case?  What did you want to achieve?