GNU bug report logs -
#50798
28.0.50; Tab line close button is off-center until it is highlighted with the mouse
Previous Next
Reported by: Po Lu <luangruo <at> yahoo.com>
Date: Sat, 25 Sep 2021 06:55:02 UTC
Severity: normal
Found in version 28.0.50
Fixed in version 28.0.60
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50798 in the body.
You can then email your comments to 50798 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 06:55:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Po Lu <luangruo <at> yahoo.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 25 Sep 2021 06:55:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The close button for each tab in a tab line is off-center unless it's
under mouse face.
Enable tab-line-mode, and compare the position of the close button (X)
in any tab when it is under mouse face to when it is not. The
difference is quite obvious.
In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
of 2021-09-25 built on chomper
Windowing system distributor 'The X.Org Foundation', version 11.0.12101002
System Description: Fedora 34 (Workstation Edition)
Configured using:
'configure --with-native-compilation --with-x-toolkit=lucid
--with-imagemagick'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM LUCID ZLIB
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 07:18:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 50798 <at> debbugs.gnu.org (full text, mbox):
Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> The close button for each tab in a tab line is off-center unless it's
> under mouse face.
>
> Enable tab-line-mode, and compare the position of the close button (X)
> in any tab when it is under mouse face to when it is not. The
> difference is quite obvious.
I'm unable to reproduce the problem, but:
> In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
> version 1.16.0, Xaw scroll bars)
I'm using a Gtk Emacs, so perhaps that makes a difference.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 08:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 25 Sep 2021 14:54:31 +0800
> From: Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
>
> The close button for each tab in a tab line is off-center unless it's
> under mouse face.
It probably has something to do with how the image spec in
tab-line-close-button is defined, specifically the margin and ascent
attributes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 08:01:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 25 Sep 2021 09:17:03 +0200
> Cc: Po Lu <luangruo <at> yahoo.com>
>
> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> > The close button for each tab in a tab line is off-center unless it's
> > under mouse face.
> >
> > Enable tab-line-mode, and compare the position of the close button (X)
> > in any tab when it is under mouse face to when it is not. The
> > difference is quite obvious.
>
> I'm unable to reproduce the problem
You need to have at least two tab-line buttons to see that, because it
only shows on the non-current tab.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 08:20:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 50798 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> You need to have at least two tab-line buttons to see that, because it
> only shows on the non-current tab.
I did:
emacs -Q
M-x tab-line-mode
M-x tab-new
M-x tab-new
And I'm not seeing any oddities when putting the mouse pointer over any
parts of the tab line.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 08:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 50798 <at> debbugs.gnu.org, luangruo <at> yahoo.com
> Date: Sat, 25 Sep 2021 10:19:31 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > You need to have at least two tab-line buttons to see that, because it
> > only shows on the non-current tab.
>
> I did:
>
> emacs -Q
> M-x tab-line-mode
> M-x tab-new
> M-x tab-new
>
> And I'm not seeing any oddities when putting the mouse pointer over any
> parts of the tab line.
Try starting Emacs with a larger font, then. As in
emacs -Q -fn "FOO-18"
where FOO is the font you get by default, like "DejaVu Sans Mono" or
something.
AFAIR, the tab-line display is entirely handled by the Emacs native
display features, so GTK should not have any effect on that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 08:31:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 50798 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Try starting Emacs with a larger font, then. As in
>
> emacs -Q -fn "FOO-18"
>
> where FOO is the font you get by default, like "DejaVu Sans Mono" or
> something.
I'm still not seeing any difference whether the mouse is over the x or
not.
No mouse:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
Mouse over the x in the second tab:
[Message part 4 (image/png, inline)]
[Message part 5 (text/plain, inline)]
The x doesn't move -- it just gets the relief around it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 08:31:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 50798 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Try starting Emacs with a larger font, then. As in
>
> emacs -Q -fn "FOO-18"
>
> where FOO is the font you get by default, like "DejaVu Sans Mono" or
> something.
If it helps, I'm using Source Code Pro-13 as the font for tab lines.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 19:16:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 50798 <at> debbugs.gnu.org (full text, mbox):
>> Try starting Emacs with a larger font, then. As in
>>
>> emacs -Q -fn "FOO-18"
>>
>> where FOO is the font you get by default, like "DejaVu Sans Mono" or
>> something.
>
> I'm still not seeing any difference whether the mouse is over the x or
> not.
I can reproduce this with a very big font on the tab-line, but not tab-bar.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 25 Sep 2021 19:45:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Sat, 25 Sep 2021 21:53:25 +0300
>
> >> Try starting Emacs with a larger font, then. As in
> >>
> >> emacs -Q -fn "FOO-18"
> >>
> >> where FOO is the font you get by default, like "DejaVu Sans Mono" or
> >> something.
> >
> > I'm still not seeing any difference whether the mouse is over the x or
> > not.
>
> I can reproduce this with a very big font on the tab-line, but not tab-bar.
We _are_ talking about the tab-line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 26 Sep 2021 05:34:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 50798 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I can reproduce this with a very big font on the tab-line, but not tab-bar.
>
> We _are_ talking about the tab-line.
Oh! `M-x new-tab' is opening a new tab bar, not a new entry on the tab
line. :-/
Yes, I can see the problem, too, on the tab line.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Mon, 27 Sep 2021 15:43:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 50798 <at> debbugs.gnu.org (full text, mbox):
>> >> Try starting Emacs with a larger font, then. As in
>> >>
>> >> emacs -Q -fn "FOO-18"
>> >>
>> >> where FOO is the font you get by default, like "DejaVu Sans Mono" or
>> >> something.
>> >
>> > I'm still not seeing any difference whether the mouse is over the x or
>> > not.
>>
>> I can reproduce this with a very big font on the tab-line, but not tab-bar.
>
> We _are_ talking about the tab-line.
The problem is that hovering mouse over the text property 'mouse-face'
set to 'tab-line-highlight' that contains ':inherit' applies its face
attributes such as :box :line-width twice thus shifting the image upwards.
This patch fixes the problem by copying face attributes from
the inherited face directly to the face used by 'mouse-face':
diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 4a751b384e..3993e625c9 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -119,7 +119,11 @@ tab-line-tab-current
:group 'tab-line-faces)
(defface tab-line-highlight
- '((t :inherit tab-line-tab))
+ '((((class color) (min-colors 88))
+ :box (:line-width 1 :style released-button)
+ :background "grey85"
+ :foreground "black")
+ (t :inverse-video nil))
"Tab line face for highlighting."
:version "27.1"
:group 'tab-line-faces)
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Mon, 27 Sep 2021 18:41:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Mon, 27 Sep 2021 18:39:13 +0300
>
> The problem is that hovering mouse over the text property 'mouse-face'
> set to 'tab-line-highlight' that contains ':inherit' applies its face
> attributes such as :box :line-width twice thus shifting the image upwards.
Sounds like a potential bug. Hod did you see that these attributes
were applied twice? And why applying the same attribute twice causes
effects that are different from applying it once?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Tue, 28 Sep 2021 19:05:03 GMT)
Full text and
rfc822 format available.
Message #44 received at 50798 <at> debbugs.gnu.org (full text, mbox):
>> The problem is that hovering mouse over the text property 'mouse-face'
>> set to 'tab-line-highlight' that contains ':inherit' applies its face
>> attributes such as :box :line-width twice thus shifting the image upwards.
>
> Sounds like a potential bug. Hod did you see that these attributes
> were applied twice? And why applying the same attribute twice causes
> effects that are different from applying it once?
It was a guess that it's applied twice. Maybe there is another bug.
At looked at the depths of 'note_mode_line_or_margin_highlight',
but don't understand what is wrong. Some X coords are miscalculated
when the mouse-face is inherited from the face with with :line-width 1.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 02 Oct 2021 10:10:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Tue, 28 Sep 2021 21:46:28 +0300
>
> >> The problem is that hovering mouse over the text property 'mouse-face'
> >> set to 'tab-line-highlight' that contains ':inherit' applies its face
> >> attributes such as :box :line-width twice thus shifting the image upwards.
> >
> > Sounds like a potential bug. Hod did you see that these attributes
> > were applied twice? And why applying the same attribute twice causes
> > effects that are different from applying it once?
>
> It was a guess that it's applied twice. Maybe there is another bug.
> At looked at the depths of 'note_mode_line_or_margin_highlight',
> but don't understand what is wrong. Some X coords are miscalculated
> when the mouse-face is inherited from the face with with :line-width 1.
Please tell more about what you saw there. Which X coordinates are
miscalculated?
And I don't think I understand the arrangement with faces for the
close button. tab-line.el says:
(defvar tab-line-close-button
(propertize " x"
'display '(image :type xpm
:file "tabs/close.xpm"
:margin (2 . 0)
:ascent center)
'keymap tab-line-tab-close-map
'mouse-face 'tab-line-close-highlight
'help-echo "Click to close tab")
"Button for closing the clicked tab.")
which seems to mean we should use 'tab-line-close-highlight' as the
mouse-face for this button. But if I invoke (tab-line-format), which
seems to be what calculates the tab-line-format, I see this:
(#(" xdisp.c x"
1 8
(tab #<buffer xdisp.c>
face tab-line-tab-inactive
mouse-face tab-line-highlight
keymap (keymap (13 . tab-line-select-tab)
(tab-line keymap (down-mouse-3 . tab-line-tab-context-menu)
(mouse-2 . tab-line-close-tab)
(down-mouse-1 . tab-line-select-tab)))
follow-link ignore)
8 10
(tab #<buffer xdisp.c>
face tab-line-tab-inactive
display (image :type xpm :file "tabs/close.xpm" :margin (2 . 0) :ascent center)
keymap (keymap (tab-line keymap (mouse-2 . tab-line-close-tab)
(mouse-1 . tab-line-close-tab)))
mouse-face tab-line-highlight ...
which seems to say we actually use the 'tab-line-highlight' face
instead for the close button?
Could you please describe how mouse-highlight faces are supposed to
work with tab-line close buttons, and preferably walk me through the
relevant code?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sat, 02 Oct 2021 19:48:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> Please tell more about what you saw there. Which X coordinates are
> miscalculated?
>
> And I don't think I understand the arrangement with faces for the
> close button. tab-line.el says:
>
> (defvar tab-line-close-button
> (propertize " x"
> 'display '(image :type xpm
> :file "tabs/close.xpm"
> :margin (2 . 0)
> :ascent center)
> 'keymap tab-line-tab-close-map
> 'mouse-face 'tab-line-close-highlight
> 'help-echo "Click to close tab")
> "Button for closing the clicked tab.")
>
> which seems to mean we should use 'tab-line-close-highlight' as the
> mouse-face for this button. But if I invoke (tab-line-format), which
> seems to be what calculates the tab-line-format, I see this:
>
> (#(" xdisp.c x"
> 1 8
> (tab #<buffer xdisp.c>
> face tab-line-tab-inactive
> mouse-face tab-line-highlight
> follow-link ignore)
> 8 10
> (tab #<buffer xdisp.c>
> face tab-line-tab-inactive
> display (image :type xpm :file "tabs/close.xpm" :margin (2 . 0) :ascent center)
> mouse-face tab-line-highlight ...
>
> which seems to say we actually use the 'tab-line-highlight' face
> instead for the close button?
>
> Could you please describe how mouse-highlight faces are supposed to
> work with tab-line close buttons, and preferably walk me through the
> relevant code?
'tab-line-close-highlight' was supposed to be applied to the close button
to emulate how the close button behaves on the tab bar where hovering mouse
over the button displays it with the face style 'released-button'.
But mouse-face of the face 'tab-line-highlight' overrides the mouse-face
'tab-line-close-highlight' in 'tab-line-tab-name-format-default'
that applies 'propertize' with 'mouse-face tab-line-highlight'.
And I can't find a way how to keep the existing 'mouse-face' property on
the close button while applying 'mouse-face tab-line-highlight' to the
rest of the tab.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 03 Oct 2021 11:50:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Sat, 02 Oct 2021 22:36:15 +0300
>
> > (defvar tab-line-close-button
> > (propertize " x"
> > 'display '(image :type xpm
> > :file "tabs/close.xpm"
> > :margin (2 . 0)
> > :ascent center)
> > 'keymap tab-line-tab-close-map
> > 'mouse-face 'tab-line-close-highlight
> > 'help-echo "Click to close tab")
> > "Button for closing the clicked tab.")
> >
> > which seems to mean we should use 'tab-line-close-highlight' as the
> > mouse-face for this button. But if I invoke (tab-line-format), which
> > seems to be what calculates the tab-line-format, I see this:
> >
> > (#(" xdisp.c x"
> > 1 8
> > (tab #<buffer xdisp.c>
> > face tab-line-tab-inactive
> > mouse-face tab-line-highlight
> > follow-link ignore)
> > 8 10
> > (tab #<buffer xdisp.c>
> > face tab-line-tab-inactive
> > display (image :type xpm :file "tabs/close.xpm" :margin (2 . 0) :ascent center)
> > mouse-face tab-line-highlight ...
> >
> > which seems to say we actually use the 'tab-line-highlight' face
> > instead for the close button?
> >
> > Could you please describe how mouse-highlight faces are supposed to
> > work with tab-line close buttons, and preferably walk me through the
> > relevant code?
>
> 'tab-line-close-highlight' was supposed to be applied to the close button
> to emulate how the close button behaves on the tab bar where hovering mouse
> over the button displays it with the face style 'released-button'.
>
> But mouse-face of the face 'tab-line-highlight' overrides the mouse-face
> 'tab-line-close-highlight' in 'tab-line-tab-name-format-default'
> that applies 'propertize' with 'mouse-face tab-line-highlight'.
> And I can't find a way how to keep the existing 'mouse-face' property on
> the close button while applying 'mouse-face tab-line-highlight' to the
> rest of the tab.
I'm not sure I follow: it is your code in
tab-line-tab-name-format-default that applies the tab-line-highlight
as mouse-face to the button:
(apply 'propertize
(concat (propertize name
'keymap tab-line-tab-map
;; Don't turn mouse-1 into mouse-2 (bug#49247)
'follow-link 'ignore)
(or (and (or buffer-p (assq 'buffer tab) (assq 'close tab))
tab-line-close-button-show
(not (eq tab-line-close-button-show
(if selected-p 'non-selected 'selected)))
tab-line-close-button)
""))
`(
tab ,tab
,@(if selected-p '(selected t))
face ,face
mouse-face tab-line-highlight))))
You should be able not to do that for the close button. Or am I
missing something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 03 Oct 2021 17:11:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 50798 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I'm not sure I follow: it is your code in
> tab-line-tab-name-format-default that applies the tab-line-highlight
> as mouse-face to the button:
>
> (apply 'propertize
> (concat (propertize name
> 'keymap tab-line-tab-map
> ;; Don't turn mouse-1 into mouse-2 (bug#49247)
> 'follow-link 'ignore)
> (or (and (or buffer-p (assq 'buffer tab) (assq 'close tab))
> tab-line-close-button-show
> (not (eq tab-line-close-button-show
> (if selected-p 'non-selected 'selected)))
> tab-line-close-button)
> ""))
> `(
> tab ,tab
> ,@(if selected-p '(selected t))
> face ,face
> mouse-face tab-line-highlight))))
>
> You should be able not to do that for the close button. Or am I
> missing something?
It's possible to put properties on the close button only, but wouldn't this be
too ugly? This means that hovering the mouse over the tab name will highlight only
the tab name without highlighting the close button. And hovering the mouse
over the close button will highlight only the close button without highlighting
the tab name. So highlighting will be separate for the close button and
the rest of the tab with such patch:
[tab-line-close-highlight.patch (text/x-diff, inline)]
diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 4a751b384e..daaa5531ef 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -125,7 +125,11 @@ tab-line-highlight
:group 'tab-line-faces)
(defface tab-line-close-highlight
- '((t :foreground "red"))
+ '((((class color) (min-colors 88))
+ :box (:line-width 1 :style released-button)
+ :background "grey85"
+ :foreground "black")
+ (t :inverse-video nil))
"Tab line face for highlighting of the close button."
:version "27.1"
:group 'tab-line-faces)
@@ -481,22 +485,23 @@ tab-line-tab-name-format-default
'tab-line-tab-inactive)))
(dolist (fn tab-line-tab-face-functions)
(setf face (funcall fn tab tabs face buffer-p selected-p)))
- (apply 'propertize
- (concat (propertize name
- 'keymap tab-line-tab-map
- ;; Don't turn mouse-1 into mouse-2 (bug#49247)
- 'follow-link 'ignore)
- (or (and (or buffer-p (assq 'buffer tab) (assq 'close tab))
- tab-line-close-button-show
- (not (eq tab-line-close-button-show
- (if selected-p 'non-selected 'selected)))
- tab-line-close-button)
- ""))
- `(
- tab ,tab
- ,@(if selected-p '(selected t))
- face ,face
- mouse-face tab-line-highlight))))
+ (concat
+ (apply 'propertize name
+ `(
+ tab ,tab
+ ,@(if selected-p '(selected t))
+ face ,face
+ mouse-face tab-line-highlight
+ keymap ,tab-line-tab-map
+ ;; Don't turn mouse-1 into mouse-2 (bug#49247)
+ follow-link ignore
+ ))
+ (or (and (or buffer-p (assq 'buffer tab) (assq 'close tab))
+ tab-line-close-button-show
+ (not (eq tab-line-close-button-show
+ (if selected-p 'non-selected 'selected)))
+ (propertize tab-line-close-button 'face face))
+ ""))))
(defun tab-line-format-template (tabs)
"Template for displaying tab line for selected window."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 03 Oct 2021 17:23:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Sun, 03 Oct 2021 19:51:40 +0300
>
> > `(
> > tab ,tab
> > ,@(if selected-p '(selected t))
> > face ,face
> > mouse-face tab-line-highlight))))
> >
> > You should be able not to do that for the close button. Or am I
> > missing something?
>
> It's possible to put properties on the close button only, but wouldn't this be
> too ugly? This means that hovering the mouse over the tab name will highlight only
> the tab name without highlighting the close button. And hovering the mouse
> over the close button will highlight only the close button without highlighting
> the tab name.
How did you intend this to look? You said previously:
> 'tab-line-close-highlight' was supposed to be applied to the close button
> to emulate how the close button behaves on the tab bar where hovering mouse
> over the button displays it with the face style 'released-button'.
>
> But mouse-face of the face 'tab-line-highlight' overrides the mouse-face
> 'tab-line-close-highlight' in 'tab-line-tab-name-format-default'
> that applies 'propertize' with 'mouse-face tab-line-highlight'.
If what you intended was not to highlight the close button
differently, then what was the intent?
> So highlighting will be separate for the close button and
> the rest of the tab with such patch:
Does this solve the problem with vertical movement of the button?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 03 Oct 2021 17:45:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 50798 <at> debbugs.gnu.org (full text, mbox):
>> It's possible to put properties on the close button only, but wouldn't this be
>> too ugly? This means that hovering the mouse over the tab name will highlight only
>> the tab name without highlighting the close button. And hovering the mouse
>> over the close button will highlight only the close button without highlighting
>> the tab name.
>
> How did you intend this to look? You said previously:
>
>> 'tab-line-close-highlight' was supposed to be applied to the close button
>> to emulate how the close button behaves on the tab bar where hovering mouse
>> over the button displays it with the face style 'released-button'.
>>
>> But mouse-face of the face 'tab-line-highlight' overrides the mouse-face
>> 'tab-line-close-highlight' in 'tab-line-tab-name-format-default'
>> that applies 'propertize' with 'mouse-face tab-line-highlight'.
>
> If what you intended was not to highlight the close button
> differently, then what was the intent?
The intent for the close button was to look exactly like
the close button on the tab-bar. Well, almost. Because
while the close button hovering looks nice on the tab-bar,
it has another problem that hovering its tab doesn't highlight it
like mouse-face highlights the tab on the tab-line.
So both the tab-bar and the tab-line are still not perfect.
>> So highlighting will be separate for the close button and
>> the rest of the tab with such patch:
>
> Does this solve the problem with vertical movement of the button?
It solves the problem because tab-line-close-highlight doesn't inherit
from other faces. It's face inheritance that caused the problem
with vertical movement of the button.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 03 Oct 2021 18:02:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Sun, 03 Oct 2021 20:42:56 +0300
>
> It solves the problem because tab-line-close-highlight doesn't inherit
> from other faces. It's face inheritance that caused the problem
> with vertical movement of the button.
I'd still like to understand why this happens. It sounds like a bug.
You said you found some coordinates miscalculated, but didn't provide
any details. Could you please provide those details, so I could try
to look at that? Debugging this is notoriously hard, because the code
is entered upon almost every mouse movement, so it is important for me
to know which code I'm investigating to be able to set up the
breakpoint conditions that avoid triggering at non-interesting
moments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Mon, 04 Oct 2021 17:48:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 50798 <at> debbugs.gnu.org (full text, mbox):
>> It solves the problem because tab-line-close-highlight doesn't inherit
>> from other faces. It's face inheritance that caused the problem
>> with vertical movement of the button.
>
> I'd still like to understand why this happens. It sounds like a bug.
>
> You said you found some coordinates miscalculated, but didn't provide
> any details. Could you please provide those details, so I could try
> to look at that? Debugging this is notoriously hard, because the code
> is entered upon almost every mouse movement, so it is important for me
> to know which code I'm investigating to be able to set up the
> breakpoint conditions that avoid triggering at non-interesting
> moments.
I don't understand how coordinates are calculated,
so I'll try to create a minimal test case for debugging.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Mon, 04 Oct 2021 17:53:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Mon, 04 Oct 2021 20:41:09 +0300
>
> >> It solves the problem because tab-line-close-highlight doesn't inherit
> >> from other faces. It's face inheritance that caused the problem
> >> with vertical movement of the button.
> >
> > I'd still like to understand why this happens. It sounds like a bug.
> >
> > You said you found some coordinates miscalculated, but didn't provide
> > any details. Could you please provide those details, so I could try
> > to look at that? Debugging this is notoriously hard, because the code
> > is entered upon almost every mouse movement, so it is important for me
> > to know which code I'm investigating to be able to set up the
> > breakpoint conditions that avoid triggering at non-interesting
> > moments.
>
> I don't understand how coordinates are calculated,
> so I'll try to create a minimal test case for debugging.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Wed, 06 Oct 2021 07:42:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 50798 <at> debbugs.gnu.org (full text, mbox):
>> I don't understand how coordinates are calculated,
>> so I'll try to create a minimal test case for debugging.
>
> Thanks.
It seems this test case exposes the problem.
The face 'test-highlight' just inherits from 'test-tab',
but hovering over the image shifts it upwards outside of the view.
The test uses the header-line to show that the problem is the same
for both the tab-line and the header-line.
(defface test
'((t :height 2.0))
"")
(defface test-tab
'((default :inherit test)
(t :box (:line-width 1 :style released-button)))
"")
(defface test-highlight
'((default :inherit test-tab))
"")
(setq header-line-format
(list (propertize " + "
'display '(image :type xpm
:file "tabs/new.xpm"
:margin (2 . 0)
:ascent center)
'face 'test-tab
'mouse-face 'test-highlight)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Thu, 07 Oct 2021 10:14:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Wed, 06 Oct 2021 10:16:27 +0300
>
> It seems this test case exposes the problem.
> The face 'test-highlight' just inherits from 'test-tab',
> but hovering over the image shifts it upwards outside of the view.
> The test uses the header-line to show that the problem is the same
> for both the tab-line and the header-line.
>
> (defface test
> '((t :height 2.0))
> "")
>
> (defface test-tab
> '((default :inherit test)
> (t :box (:line-width 1 :style released-button)))
> "")
>
> (defface test-highlight
> '((default :inherit test-tab))
> "")
>
> (setq header-line-format
> (list (propertize " + "
> 'display '(image :type xpm
> :file "tabs/new.xpm"
> :margin (2 . 0)
> :ascent center)
> 'face 'test-tab
> 'mouse-face 'test-highlight)))
Thanks, but I'm not sure I understand what you expected and why. the
face 'test' is defined to be twice the width of the default face. The
face test-highlight inherits from it, but the 't' case doesn't change
the :height attribute, so it ends up having the same height, just with
the :box attribute. That's why it looks bad on the header line: its
height is greater than that of header-line.
What did you expect to happen with these definitions of faces?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Thu, 07 Oct 2021 12:54:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 07 Oct 2021 13:13:37 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: luangruo <at> yahoo.com, larsi <at> gnus.org, 50798 <at> debbugs.gnu.org
>
> The face 'test' is defined to be twice the width of the default
> face. ^^^^^
Sorry, that was supposed to be "height", of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 10 Oct 2021 17:34:03 GMT)
Full text and
rfc822 format available.
Message #83 received at 50798 <at> debbugs.gnu.org (full text, mbox):
>> (defface test
>> '((t :height 2.0))
>> "")
>>
>> (defface test-tab
>> '((default :inherit test)
>> (t :box (:line-width 1 :style released-button)))
>> "")
>>
>> (defface test-highlight
>> '((default :inherit test-tab))
>> "")
>
> Thanks, but I'm not sure I understand what you expected and why. the
> face 'test' is defined to be twice the width of the default face. The
> face test-highlight inherits from it, but the 't' case doesn't change
> the :height attribute, so it ends up having the same height, just with
> the :box attribute. That's why it looks bad on the header line: its
> height is greater than that of header-line.
>
> What did you expect to happen with these definitions of faces?
My previous patch avoided inheriting from the face that changes the
height of the mouse-highlight face. Maybe it was the right solution?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Sun, 10 Oct 2021 17:59:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 50798 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, luangruo <at> yahoo.com, 50798 <at> debbugs.gnu.org
> Date: Sun, 10 Oct 2021 20:04:05 +0300
>
> >> (defface test
> >> '((t :height 2.0))
> >> "")
> >>
> >> (defface test-tab
> >> '((default :inherit test)
> >> (t :box (:line-width 1 :style released-button)))
> >> "")
> >>
> >> (defface test-highlight
> >> '((default :inherit test-tab))
> >> "")
> >
> > Thanks, but I'm not sure I understand what you expected and why. the
> > face 'test' is defined to be twice the width of the default face. The
> > face test-highlight inherits from it, but the 't' case doesn't change
> > the :height attribute, so it ends up having the same height, just with
> > the :box attribute. That's why it looks bad on the header line: its
> > height is greater than that of header-line.
> >
> > What did you expect to happen with these definitions of faces?
>
> My previous patch avoided inheriting from the face that changes the
> height of the mouse-highlight face. Maybe it was the right solution?
Did you intend that the face which inherited will NOT have the changed
size like the one it inherited from? If so, not inheriting is
probably the easiest solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50798; Package
emacs.
(Mon, 11 Oct 2021 18:30:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 50798 <at> debbugs.gnu.org (full text, mbox):
close 50798 28.0.60
quit
>> >> (defface test
>> >> '((t :height 2.0))
>> >> "")
>> >>
>> >> (defface test-highlight
>> >> '((default :inherit test-tab))
>> >> "")
>> >
>> > What did you expect to happen with these definitions of faces?
>>
>> My previous patch avoided inheriting from the face that changes the
>> height of the mouse-highlight face. Maybe it was the right solution?
>
> Did you intend that the face which inherited will NOT have the changed
> size like the one it inherited from? If so, not inheriting is
> probably the easiest solution.
Yes, no need to change size on mouse highlighting, so I pushed this fix.
One possible problem is that some themes might break. But I checked
that modus-themes.el is well-designed, so its face inheritance doesn't break
because its parent face doesn't use the face attribute :height:
`(tab-line-highlight ((,class :inherit modus-themes-active-blue)))
bug marked as fixed in version 28.0.60, send any further explanations to
50798 <at> debbugs.gnu.org and Po Lu <luangruo <at> yahoo.com>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Mon, 11 Oct 2021 18:30:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 09 Nov 2021 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 162 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.