GNU bug report logs -
#50424
27.2; Tab bar button mouse face not clearing entirely
Previous Next
Reported by: Po Lu <luangruo <at> yahoo.com>
Date: Mon, 6 Sep 2021 08:14:02 UTC
Severity: normal
Tags: fixed
Found in version 27.2
Fixed in version 28.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #74 received at 50424 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: alan <at> idiocy.org, luangruo <at> yahoo.com, 50424 <at> 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.
This bug report was last modified 3 years and 288 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.