From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50424: 27.2; Tab bar button mouse face not clearing entirely Date: Sun, 12 Sep 2021 11:35:33 +0300 Message-ID: <83k0jmfay2.fsf@gnu.org> References: <87eea2cebb.fsf.ref@yahoo.com> <87eea2cebb.fsf@yahoo.com> <83eea2rn8z.fsf@gnu.org> <87h7exc2dk.fsf@yahoo.com> <83lf49r4bc.fsf@gnu.org> <87czplb51o.fsf@yahoo.com> <83ilzcpt0d.fsf@gnu.org> <83mtonob41.fsf@gnu.org> <87tuiryn17.fsf@mail.linkov.net> <831r5uhpd3.fsf@gnu.org> <8735qazyjv.fsf@mail.linkov.net> <83zgsifob4.fsf@gnu.org> <87zgsii8cy.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16379"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 50424@debbugs.gnu.org, alan@idiocy.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 12 10:36:20 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mPKyJ-000435-EQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Sep 2021 10:36:19 +0200 Original-Received: from localhost ([::1]:54330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mPKyG-0006fr-Dz for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Sep 2021 04:36:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mPKy2-0006f9-GX for bug-gnu-emacs@gnu.org; Sun, 12 Sep 2021 04:36:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58684) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mPKy2-0006ui-6e for bug-gnu-emacs@gnu.org; Sun, 12 Sep 2021 04:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mPKy2-0005b5-1N for bug-gnu-emacs@gnu.org; Sun, 12 Sep 2021 04:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Sep 2021 08:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50424 X-GNU-PR-Package: emacs Original-Received: via spool by 50424-submit@debbugs.gnu.org id=B50424.163143576021508 (code B ref 50424); Sun, 12 Sep 2021 08:36:01 +0000 Original-Received: (at 50424) by debbugs.gnu.org; 12 Sep 2021 08:36:00 +0000 Original-Received: from localhost ([127.0.0.1]:41997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPKy0-0005aq-7Z for submit@debbugs.gnu.org; Sun, 12 Sep 2021 04:36:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPKxv-0005aY-Nk for 50424@debbugs.gnu.org; Sun, 12 Sep 2021 04:35:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53742) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mPKxm-0006jJ-UZ; Sun, 12 Sep 2021 04:35:48 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1946 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mPKxl-00046l-5z; Sun, 12 Sep 2021 04:35:46 -0400 In-Reply-To: <87zgsii8cy.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 12 Sep 2021 10:06:09 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214120 Archived-At: > From: Juri Linkov > 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.