bug#50424: 27.2; Tab bar button mouse face not clearing entirely

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: alan@idiocy.org,  luangruo@yahoo.com,  50424@debbugs.gnu.org
> Date: Sun, 12 Sep 2021 10:06:09 +0300
> 
> > Then I don't understand the two horizontally-adjacent images.  What
> > are they? two separate frame?  If they are two frames, then where are
> > the frame decorations?  In short, I don't understand what am I seeing
> > there, and how did you get this display.
> 
> These are two separate images that show the changed tab dimensions
> before changes when :margin was (2 . 0), and after changes
> when now :margin is 4.
> 
> > And also, when you say "buttons are not vertically aligned", what
> > exactly do you mean?  Not aligned with what?
> 
> Now buttons are not aligned to the baseline, and thus are
> not centered vertically anymore.

Isn't that evidence that something is wrong in how the labels and
buttons are displayed?  The margin of 4 is symmetrical, so why aren't
the buttons centered?  And why do we need to use zero vertical margin
to get them centered?  This seems to mean we have some hidden problem
here.

> This patch restores the original tab dimensions, while also keeps fixed
> the reported problem of mouse face not clearing entirely:
> 
> diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
> index 8be08d4b8b..edbadec09d 100644
> --- a/lisp/tab-bar.el
> +++ b/lisp/tab-bar.el
> @@ -161,7 +161,7 @@ tab-bar--load-buttons
>      (add-text-properties 0 (length tab-bar-new-button)
>                           `(display (image :type xpm
>                                            :file "tabs/new.xpm"
> -                                          :margin ,tab-bar-button-margin
> +                                          :margin ,(cons 
> tab-bar-button-margin 0)
>                                            :ascent center))
>                           tab-bar-new-button))

Sorry, this cannot be right.  tab-bar-button-margin is documented and
used as determining the button margins completely:

      doc: /* Margin around tab-bar buttons in pixels.
  If an integer, use that for both horizontal and vertical margins.
  Otherwise, value should be a pair of integers `(HORZ . VERT)' with
  HORZ specifying the horizontal margin, and VERT specifying the
  vertical margin.  */);

We cannot arbitrarily decide that the value matters only for the
horizontal margin, but not for the vertical one.  When the user or a
Lisp program change the value of that variable, they should get the
effect they expect based on the documentation.  Also, the code in
xterm.c/w32term.c clearly behaves according to the doc string of
tab-bar-button-margin, which is yet another reason not to do what you
propose.  And what will happen with your code if tab-bar-button-margin
is set to a cons cell, as allowed by the documentation above?

If we want the default value of tab-bar-button-margin to be a cons
cell, let's change the default value to be a cons cell, it's not more
complicated than setting it to a scalar, even in C.  But tab-bar.el
should use in its image specs the exact value of
tab-bar-button-margin, it cannot decide to change it behind the back
of the caller.