GNU bug report logs - #50424
27.2; Tab bar button mouse face not clearing entirely

Previous Next

Package: emacs;

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: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: luangruo <at> yahoo.com, 50424 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#50424: 27.2; Tab bar button mouse face not clearing entirely
Date: Sun, 12 Sep 2021 11:35:33 +0300
> 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.