GNU bug report logs - #76394
mouse-face property not working in tab-bar

Previous Next

To reply to this bug, email your comments to 76394 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: mouse-face property not working in tab-bar
Date: Tue, 18 Feb 2025 10:04:10 -0500

[Message part 1 (text/plain, inline)]

I was trying to make a simple aesthetic change to tab-bar to highlight a
tab when it is moused over.  mouse-face seems to work in tab-line,
header-line, and obviously in mode-line.  Mouse events are processed in the
tab-bar window.  Am I missing something obvious?  I tested in 29.4 and in
master.

emacs -Q -l tab-bar-mouse-face.el

tab-bar-mouse-face.el:

(tab-bar-mode)
(defun my/tab-bar-tab-name-format-function (tab i)
  (propertize
   (tab-bar-tab-name-format-default tab i)
   'mouse-face '(:inverse-video t)))
(setopt tab-bar-tab-name-format-function
#'my/tab-bar-tab-name-format-function)

-Stephane

P.S. I searched for a related bug but did not find one so this could be a
duplicate bug report.

[Message part 2 (text/html, inline)]

Message #8 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Tue, 18 Feb 2025 19:14:20 +0200

> I was trying to make a simple aesthetic change to tab-bar to highlight a
> tab when it is moused over.  mouse-face seems to work in tab-line,
> header-line, and obviously in mode-line.  Mouse events are processed in the
> tab-bar window.  Am I missing something obvious?  I tested in 29.4 and in
> master.

Indeed, this would be a nice feature.  Patches welcome.

Message #11 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 24 Feb 2025 10:27:11 -0500

[Message part 1 (text/plain, inline)]

First-cut patch for mouse-face handling on tab-bar items.  I left the
default handling code in place not being sure what it really is intended to
do (which appears to be nothing?).  It looks copied
from note_tool_bar_highlight but I wasn't sure.  (xdisp internals are fun.
It's a work of art.)

-Stephane

On Tue, Feb 18, 2025 at 12:14 PM Juri Linkov <juri <at> linkov.net> wrote:

> > I was trying to make a simple aesthetic change to tab-bar to highlight a
> > tab when it is moused over.  mouse-face seems to work in tab-line,
> > header-line, and obviously in mode-line.  Mouse events are processed in
> the
> > tab-bar window.  Am I missing something obvious?  I tested in 29.4 and in
> > master.
>
> Indeed, this would be a nice feature.  Patches welcome.
>

[Message part 2 (text/html, inline)]

[0001-Handle-mouse-face-properties-on-tab-bar-tabs-bug-763.patch (application/octet-stream, attachment)]

Message #14 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 20:22:18 +0200

> First-cut patch for mouse-face handling on tab-bar items.  I left the
> default handling code in place not being sure what it really is intended to
> do (which appears to be nothing?).  It looks copied from
> note_tool_bar_highlight but I wasn't sure.  (xdisp internals are fun.  It's
> a work of art.)

Thanks.  What is the status of this patch?  I tried it out,
but can't see where is handles mouse-face.

Message #17 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 13:30:59 -0500

[Message part 1 (text/plain, inline)]

Thanks for checking out the patch.  Try this:

(defun my/tab-bar-tab-name-format-function (tab i)
  (propertize
   (tab-bar-tab-name-format-default tab i)
   'mouse-face '(:inverse-video t))) ; or a named face
(setopt tab-bar-tab-name-format-function
#'my/tab-bar-tab-name-format-function)

And move the mouse over the tab. It should invert. It does for me.

On Thu, Feb 27, 2025 at 1:23 PM Juri Linkov <juri <at> linkov.net> wrote:

> > First-cut patch for mouse-face handling on tab-bar items.  I left the
> > default handling code in place not being sure what it really is intended
> to
> > do (which appears to be nothing?).  It looks copied from
> > note_tool_bar_highlight but I wasn't sure.  (xdisp internals are fun.
> It's
> > a work of art.)
>
> Thanks.  What is the status of this patch?  I tried it out,
> but can't see where is handles mouse-face.
>

[Message part 2 (text/html, inline)]

Message #20 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 20:41:54 +0200

> (defun my/tab-bar-tab-name-format-function (tab i)
>   (propertize
>    (tab-bar-tab-name-format-default tab i)
>    'mouse-face '(:inverse-video t))) ; or a named face
> (setopt tab-bar-tab-name-format-function
> #'my/tab-bar-tab-name-format-function)
>
> And move the mouse over the tab. It should invert. It does for me.

Thanks, now it works.  The requirement is that the tab-bar-mode
should be disabled before evaluating the above code.  Otherwise,
with already enabled tab-bar-mode it has no effect.

Message #23 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 13:43:54 -0500

[Message part 1 (text/plain, inline)]

I assumed you knew how to use tab-bar :) I rarely use emojis but this one I
couldn't help myself.

It also works with mouse-face on any spans of glyphs embedded in the name
string.

On Thu, Feb 27, 2025 at 1:42 PM Juri Linkov <juri <at> linkov.net> wrote:

> > (defun my/tab-bar-tab-name-format-function (tab i)
> >   (propertize
> >    (tab-bar-tab-name-format-default tab i)
> >    'mouse-face '(:inverse-video t))) ; or a named face
> > (setopt tab-bar-tab-name-format-function
> > #'my/tab-bar-tab-name-format-function)
> >
> > And move the mouse over the tab. It should invert. It does for me.
>
> Thanks, now it works.  The requirement is that the tab-bar-mode
> should be disabled before evaluating the above code.  Otherwise,
> with already enabled tab-bar-mode it has no effect.
>

[Message part 2 (text/html, inline)]

Message #26 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 21:06:49 +0200

> I assumed you knew how to use tab-bar :) I rarely use emojis but this one I
> couldn't help myself.
>
> It also works with mouse-face on any spans of glyphs embedded in the name
> string.

But this doesn't look normal, don't you think so?
tab-bar-mode enabled, then later disabled,
code evaluated, enabled again, and no effect.
Something is wrong here?  There are no other settings
that behave that way.

>     > (defun my/tab-bar-tab-name-format-function (tab i)
>     >   (propertize
>     >    (tab-bar-tab-name-format-default tab i)
>     >    'mouse-face '(:inverse-video t))) ; or a named face
>     > (setopt tab-bar-tab-name-format-function
>     > #'my/tab-bar-tab-name-format-function)
>     >
>     > And move the mouse over the tab. It should invert. It does for me.
>
>     Thanks, now it works.  The requirement is that the tab-bar-mode
>     should be disabled before evaluating the above code.  Otherwise,
>     with already enabled tab-bar-mode it has no effect.

Message #29 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 14:13:12 -0500

[Message part 1 (text/plain, inline)]

My patch is all in xdisp.c so I don't follow.

On Thu, Feb 27, 2025 at 14:07 Juri Linkov <juri <at> linkov.net> wrote:

> > I assumed you knew how to use tab-bar :) I rarely use emojis but this
> one I
> > couldn't help myself.
> >
> > It also works with mouse-face on any spans of glyphs embedded in the name
> > string.
>
> But this doesn't look normal, don't you think so?
> tab-bar-mode enabled, then later disabled,
> code evaluated, enabled again, and no effect.
> Something is wrong here?  There are no other settings
> that behave that way.
>
> >     > (defun my/tab-bar-tab-name-format-function (tab i)
> >     >   (propertize
> >     >    (tab-bar-tab-name-format-default tab i)
> >     >    'mouse-face '(:inverse-video t))) ; or a named face
> >     > (setopt tab-bar-tab-name-format-function
> >     > #'my/tab-bar-tab-name-format-function)
> >     >
> >     > And move the mouse over the tab. It should invert. It does for me.
> >
> >     Thanks, now it works.  The requirement is that the tab-bar-mode
> >     should be disabled before evaluating the above code.  Otherwise,
> >     with already enabled tab-bar-mode it has no effect.
>

[Message part 2 (text/html, inline)]

Message #32 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 14:14:33 -0500

[Message part 1 (text/plain, inline)]

I assumed that once the xdisp changes were deemed acceptable, we'd suggest
a tab bar highlight face. That would be in lisp.

On Thu, Feb 27, 2025 at 14:13 Ship Mints <shipmints <at> gmail.com> wrote:

> My patch is all in xdisp.c so I don't follow.
>
> On Thu, Feb 27, 2025 at 14:07 Juri Linkov <juri <at> linkov.net> wrote:
>
>> > I assumed you knew how to use tab-bar :) I rarely use emojis but this
>> one I
>> > couldn't help myself.
>> >
>> > It also works with mouse-face on any spans of glyphs embedded in the
>> name
>> > string.
>>
>> But this doesn't look normal, don't you think so?
>> tab-bar-mode enabled, then later disabled,
>> code evaluated, enabled again, and no effect.
>> Something is wrong here?  There are no other settings
>> that behave that way.
>>
>> >     > (defun my/tab-bar-tab-name-format-function (tab i)
>> >     >   (propertize
>> >     >    (tab-bar-tab-name-format-default tab i)
>> >     >    'mouse-face '(:inverse-video t))) ; or a named face
>> >     > (setopt tab-bar-tab-name-format-function
>> >     > #'my/tab-bar-tab-name-format-function)
>> >     >
>> >     > And move the mouse over the tab. It should invert. It does for me.
>> >
>> >     Thanks, now it works.  The requirement is that the tab-bar-mode
>> >     should be disabled before evaluating the above code.  Otherwise,
>> >     with already enabled tab-bar-mode it has no effect.
>>
>

[Message part 2 (text/html, inline)]

Message #35 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 21:15:43 +0200

> My patch is all in xdisp.c so I don't follow. 

I see now that even when tab-bar-mode is enabled,
the settings take effect after refreshing the tab-bar.
So I just needed more time to test ;-)

>     > I assumed you knew how to use tab-bar :) I rarely use emojis but this
>     one I
>     > couldn't help myself.
>     >
>     > It also works with mouse-face on any spans of glyphs embedded in the
>     name
>     > string.
>
>     But this doesn't look normal, don't you think so?
>     tab-bar-mode enabled, then later disabled,
>     code evaluated, enabled again, and no effect.
>     Something is wrong here?  There are no other settings
>     that behave that way.
>
>     >     > (defun my/tab-bar-tab-name-format-function (tab i)
>     >     >   (propertize
>     >     >    (tab-bar-tab-name-format-default tab i)
>     >     >    'mouse-face '(:inverse-video t))) ; or a named face
>     >     > (setopt tab-bar-tab-name-format-function
>     >     > #'my/tab-bar-tab-name-format-function)
>     >     >
>     >     > And move the mouse over the tab. It should invert. It does for
>     me.
>     >
>     >     Thanks, now it works.  The requirement is that the tab-bar-mode
>     >     should be disabled before evaluating the above code.  Otherwise,
>     >     with already enabled tab-bar-mode it has no effect.

Message #38 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 27 Feb 2025 22:14:55 +0200

> Cc: 76394 <at> debbugs.gnu.org
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Mon, 24 Feb 2025 10:27:11 -0500
> 


> From 13045c1823d81a1f7a2aea2f9e7c81436ce16efa Mon Sep 17 00:00:00 2001
> From: shipmints <shipmints <at> gmail.com>
> Date: Sat, 22 Feb 2025 05:13:05 -0500
> Subject: [PATCH] Handle mouse-face properties on tab-bar tabs (bug#76394)

Thanks, I have a few comments:

> * src/xdisp.c (note_tab_bar_highlight):
> Handle mouse-face properties, if found.  Realize the face if necessary.

Please reformat this log entry according to our conventions (see
examples in Git).

> +      if (STRINGP (string))
> +        {
> +          /* Compute starting column of the tab-bar-item to adjust col
> +             of the mouse face relative to row_start_glyph.
> +
> +             tab_bar_item_info does not contain the absolute starting
> +             offset of the item.  We compute it by looking backwards
> +             until we find a glyph that belongs to a previous tab bar
> +             item, or if this is the first item. */

Please indent with TABs and SPCs, not just with SPCs, per our
conventions for C source files.  (This is supposed to happen
automatically due to our .dir-locals.el, unless you disable that for
some reason.)

> +                break; /* Just before the beginning of this item. */
                                                                   ^^
Please leave two spaces at the end of a comment (here and elsewhere in
the patch).

> +          mouse_face = Fget_text_property (make_fixnum (hpos_caption),
> +                                           Qmouse_face, string);
> +          if (!NILP (mouse_face))
> +            {
> +              mouse_face_id = lookup_named_face (NULL, f, mouse_face, false);
                                                    ^^^^
Why NULL and not 'w'?

> +	  if ( EQ (window, hlinfo->mouse_face_window)
> +	       && (!row->reversed_p

Can a glyph row that corresponds to a tab bar be reversed?  IOW, can
the tab bar be ever displayed right-to-left?  I don't think so, but if
I'm wrong, can you describe a scenario where it can happen?

Message #41 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 11:20:31 -0500

[Message part 1 (text/plain, inline)]

On Thu, Feb 27, 2025 at 3:15 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Subject: [PATCH] Handle mouse-face properties on tab-bar tabs (bug#76394)
>
> Thanks, I have a few comments:
>
> > * src/xdisp.c (note_tab_bar_highlight):
> > Handle mouse-face properties, if found.  Realize the face if necessary.
>
> Please reformat this log entry according to our conventions (see
> examples in Git).
>

I tried.  I hope the revised log is acceptable.

Modeled after Juri's 24c4bc1:

* src/xdisp.c (note_tab_bar_highlight): Remove fallback for
help_echo_string.
Don't use TAB_BAR_ITEM_CAPTION as the default value
when TAB_BAR_ITEM_HELP is not specified (bug#73050).

And Eli's 1136963:

; * src/xdisp.c (maybe_produce_line_number): Fix last change (bug#76362).

> +      if (STRINGP (string))
> > +        {
> > +          /* Compute starting column of the tab-bar-item to adjust col
> > +             of the mouse face relative to row_start_glyph.
> > +
> > +             tab_bar_item_info does not contain the absolute starting
> > +             offset of the item.  We compute it by looking backwards
> > +             until we find a glyph that belongs to a previous tab bar
> > +             item, or if this is the first item. */
>
> Please indent with TABs and SPCs, not just with SPCs, per our
> conventions for C source files.  (This is supposed to happen
> automatically due to our .dir-locals.el, unless you disable that for
> some reason.)
>

I had a misconfiguration of tree sitter for C/C++ that borked the mode to
not match .dir-locals.  I fixed that.

> +                break; /* Just before the beginning of this item. */
>                                                                    ^^
> Please leave two spaces at the end of a comment (here and elsewhere in
> the patch).
>

Done.


> > +          mouse_face = Fget_text_property (make_fixnum (hpos_caption),
> > +                                           Qmouse_face, string);
> > +          if (!NILP (mouse_face))
> > +            {
> > +              mouse_face_id = lookup_named_face (NULL, f, mouse_face,
> false);
>                                                     ^^^^
> Why NULL and not 'w'?
>

I wasn't sure remaps were valid in tab_bar.  I put w in now, just in case
they are.

> +       if ( EQ (window, hlinfo->mouse_face_window)
> > +            && (!row->reversed_p
>
> Can a glyph row that corresponds to a tab bar be reversed?  IOW, can
> the tab bar be ever displayed right-to-left?  I don't think so, but if
> I'm wrong, can you describe a scenario where it can happen?
>

There's a comment in display_tab_bar:

  /* FIXME: This should be controlled by a user option.  See the
     comments in redisplay_tool_bar and display_mode_line about
     this.  */
  it.paragraph_embedding = L2R;

I figured let's be defensive for when this is implemented.

Also added tab-bar-tab-highlight face in lisp/tab-bar.el.

-Stephane

[Message part 2 (text/html, inline)]

[0001-mouse-face-properties-on-tab-bar-tab-captions-bug-76.patch (application/octet-stream, attachment)]

Message #44 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 19:42:54 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 28 Feb 2025 11:20:31 -0500
> Cc: juri <at> linkov.net, 76394 <at> debbugs.gnu.org
> 
> I tried.  I hope the revised log is acceptable.

Thanks, a minor comment about that below.

>  > +       if ( EQ (window, hlinfo->mouse_face_window)
>  > +            && (!row->reversed_p
> 
>  Can a glyph row that corresponds to a tab bar be reversed?  IOW, can
>  the tab bar be ever displayed right-to-left?  I don't think so, but if
>  I'm wrong, can you describe a scenario where it can happen?
> 
> There's a comment in display_tab_bar:
> 
>   /* FIXME: This should be controlled by a user option.  See the
>      comments in redisplay_tool_bar and display_mode_line about
>      this.  */
>   it.paragraph_embedding = L2R;
> 
> I figured let's be defensive for when this is implemented.

What we usually do in these cases is to put an assertion there, so
that if the condition we assume to always be true ever isn't, we are
informed about that in the most violent manner.

> * src/xdisp.c (note_tab_bar_highlight): mouse-face properties.

This is not a complete sentence.  I guess you meant something like

  * src/xdisp.c (note_tab_bar_highlight): Handle mouse-face property.

> * lisp/tab-bar.el: Add face tab-bar-tab-highlight.

Our usual style is a bit different:

  * lisp/tab-bar.el (tab-bar-tab-highlight): New face.

But I have a question: why add this face if there's no code that uses
it?  Or what did I miss?

> -  bool close_p;
> -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
> -  int rc;
> +    Lisp_Object window = f->tab_bar_window;
> +    struct window *w = XWINDOW (window);
> +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);

Why does indention of the new code use 4 spaces, not 2?

Message #47 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 13:06:54 -0500

[Message part 1 (text/plain, inline)]

On Fri, Feb 28, 2025 at 12:42 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 28 Feb 2025 11:20:31 -0500
> > Cc: juri <at> linkov.net, 76394 <at> debbugs.gnu.org
> >
> > I tried.  I hope the revised log is acceptable.
>
> Thanks, a minor comment about that below.
>
> >  > +       if ( EQ (window, hlinfo->mouse_face_window)
> >  > +            && (!row->reversed_p
> >
> >  Can a glyph row that corresponds to a tab bar be reversed?  IOW, can
> >  the tab bar be ever displayed right-to-left?  I don't think so, but if
> >  I'm wrong, can you describe a scenario where it can happen?
> >
> > There's a comment in display_tab_bar:
> >
> >   /* FIXME: This should be controlled by a user option.  See the
> >      comments in redisplay_tool_bar and display_mode_line about
> >      this.  */
> >   it.paragraph_embedding = L2R;
> >
> > I figured let's be defensive for when this is implemented.
>
> What we usually do in these cases is to put an assertion there, so
> that if the condition we assume to always be true ever isn't, we are
> informed about that in the most violent manner.
>

So we'll be super duper defensive, then.  Should I leave the "future" code
in place after the assertion or do you think it's easy enough to recreate
if/when needed?

> * src/xdisp.c (note_tab_bar_highlight): mouse-face properties.
>
> This is not a complete sentence.  I guess you meant something like
>
>   * src/xdisp.c (note_tab_bar_highlight): Handle mouse-face property.
>
> > * lisp/tab-bar.el: Add face tab-bar-tab-highlight.
>
> Our usual style is a bit different:
>
>   * lisp/tab-bar.el (tab-bar-tab-highlight): New face.
>

I'll update.

But I have a question: why add this face if there's no code that uses
> it?  Or what did I miss?
>
> > -  bool close_p;
> > -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
> > -  int rc;
> > +    Lisp_Object window = f->tab_bar_window;
> > +    struct window *w = XWINDOW (window);
> > +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
>

The idea is that now that there's mouse-face support, people can customize
a dedicated face for tab-bar tabs.  This is in line with tab-line tabs and
its highlight face.

Why does indention of the new code use 4 spaces, not 2?
>

No idea.  The .dir-locals.el is in effect.  I checked several buffer locals
to ensure that was true.  What should I look at to help analyze this?  I
suspect others will have this issue as well when helping with C code.

-Stephane

[Message part 2 (text/html, inline)]

Message #50 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 13:20:49 -0500

[Message part 1 (text/plain, inline)]

On Fri, Feb 28, 2025 at 1:06 PM Ship Mints <shipmints <at> gmail.com> wrote:

>
> Why does indention of the new code use 4 spaces, not 2?
>>
>
> No idea.  The .dir-locals.el is in effect.  I checked several buffer
> locals to ensure that was true.  What should I look at to help analyze
> this?  I suspect others will have this issue as well when helping with C
> code.
>

My default c-basic-offset is 4.  .dir-locals.el is silent on that, so I get
mine rather than yours.  Would you like me to update .dir.locals.el?  I
will put a locals-2 with the correction, at least that will get me started.

[Message part 2 (text/html, inline)]

Message #53 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 13:52:30 -0500

[Message part 1 (text/plain, inline)]

This should be a "clean" patch.  The R2L code can be removed or left in
place.  I put a comment on the assertion to that effect.

On Fri, Feb 28, 2025 at 1:06 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Fri, Feb 28, 2025 at 12:42 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Ship Mints <shipmints <at> gmail.com>
>> > Date: Fri, 28 Feb 2025 11:20:31 -0500
>> > Cc: juri <at> linkov.net, 76394 <at> debbugs.gnu.org
>> >
>> > I tried.  I hope the revised log is acceptable.
>>
>> Thanks, a minor comment about that below.
>>
>> >  > +       if ( EQ (window, hlinfo->mouse_face_window)
>> >  > +            && (!row->reversed_p
>> >
>> >  Can a glyph row that corresponds to a tab bar be reversed?  IOW, can
>> >  the tab bar be ever displayed right-to-left?  I don't think so, but if
>> >  I'm wrong, can you describe a scenario where it can happen?
>> >
>> > There's a comment in display_tab_bar:
>> >
>> >   /* FIXME: This should be controlled by a user option.  See the
>> >      comments in redisplay_tool_bar and display_mode_line about
>> >      this.  */
>> >   it.paragraph_embedding = L2R;
>> >
>> > I figured let's be defensive for when this is implemented.
>>
>> What we usually do in these cases is to put an assertion there, so
>> that if the condition we assume to always be true ever isn't, we are
>> informed about that in the most violent manner.
>>
>
> So we'll be super duper defensive, then.  Should I leave the "future" code
> in place after the assertion or do you think it's easy enough to recreate
> if/when needed?
>
> > * src/xdisp.c (note_tab_bar_highlight): mouse-face properties.
>>
>> This is not a complete sentence.  I guess you meant something like
>>
>>   * src/xdisp.c (note_tab_bar_highlight): Handle mouse-face property.
>>
>> > * lisp/tab-bar.el: Add face tab-bar-tab-highlight.
>>
>> Our usual style is a bit different:
>>
>>   * lisp/tab-bar.el (tab-bar-tab-highlight): New face.
>>
>
> I'll update.
>
> But I have a question: why add this face if there's no code that uses
>> it?  Or what did I miss?
>>
>> > -  bool close_p;
>> > -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
>> > -  int rc;
>> > +    Lisp_Object window = f->tab_bar_window;
>> > +    struct window *w = XWINDOW (window);
>> > +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
>>
>
> The idea is that now that there's mouse-face support, people can customize
> a dedicated face for tab-bar tabs.  This is in line with tab-line tabs and
> its highlight face.
>
> Why does indention of the new code use 4 spaces, not 2?
>>
>
> No idea.  The .dir-locals.el is in effect.  I checked several buffer
> locals to ensure that was true.  What should I look at to help analyze
> this?  I suspect others will have this issue as well when helping with C
> code.
>
> -Stephane
>

[Message part 2 (text/html, inline)]

[0001-mouse-face-properties-on-tab-bar-tab-captions-bug-76.patch (application/octet-stream, attachment)]

Message #56 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 13:56:03 -0500

[Message part 1 (text/plain, inline)]

On Fri, Feb 28, 2025 at 1:20 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Fri, Feb 28, 2025 at 1:06 PM Ship Mints <shipmints <at> gmail.com> wrote:
>
>>
>> Why does indention of the new code use 4 spaces, not 2?
>>>
>>
>> No idea.  The .dir-locals.el is in effect.  I checked several buffer
>> locals to ensure that was true.  What should I look at to help analyze
>> this?  I suspect others will have this issue as well when helping with C
>> code.
>>
>
> My default c-basic-offset is 4.  .dir-locals.el is silent on that, so I
> get mine rather than yours.  Would you like me to update .dir.locals.el?  I
> will put a locals-2 with the correction, at least that will get me started.
>

It seems the "gnu" style says c-basic-offset 2 but I guess cc-mode will not
override an explicit option setting?

[Message part 2 (text/html, inline)]

Message #59 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 21:00:06 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 28 Feb 2025 13:06:54 -0500
> Cc: juri <at> linkov.net, 76394 <at> debbugs.gnu.org
> 
>  >   /* FIXME: This should be controlled by a user option.  See the
>  >      comments in redisplay_tool_bar and display_mode_line about
>  >      this.  */
>  >   it.paragraph_embedding = L2R;
>  > 
>  > I figured let's be defensive for when this is implemented.
> 
>  What we usually do in these cases is to put an assertion there, so
>  that if the condition we assume to always be true ever isn't, we are
>  informed about that in the most violent manner.
> 
> So we'll be super duper defensive, then.  Should I leave the "future" code in place after the assertion or do
> you think it's easy enough to recreate if/when needed? 

I'd prefer to avoid testing for a condition that is always true.

>    * lisp/tab-bar.el (tab-bar-tab-highlight): New face.
> 
> I'll update.
> 
>  But I have a question: why add this face if there's no code that uses
>  it?  Or what did I miss?
> 
>  > -  bool close_p;
>  > -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
>  > -  int rc;
>  > +    Lisp_Object window = f->tab_bar_window;
>  > +    struct window *w = XWINDOW (window);
>  > +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
> 
> The idea is that now that there's mouse-face support, people can customize a dedicated face for tab-bar
> tabs.  This is in line with tab-line tabs and its highlight face.

Sounds strange to me to have a face that no other code uses.  I would
understand if this face was by default identical to the 'default'
face, and was used by the tab bar.

Message #62 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 14:04:28 -0500

[Message part 1 (text/plain, inline)]

On Fri, Feb 28, 2025 at 2:00 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> >
> > So we'll be super duper defensive, then.  Should I leave the "future"
> code in place after the assertion or do
> > you think it's easy enough to recreate if/when needed?
>
> I'd prefer to avoid testing for a condition that is always true.
>

I'll remove the code.  It's in the archive in older patches, if ever needed.

>    * lisp/tab-bar.el (tab-bar-tab-highlight): New face.
> >
> > I'll update.
> >
> >  But I have a question: why add this face if there's no code that uses
> >  it?  Or what did I miss?
> >
> >  > -  bool close_p;
> >  > -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
> >  > -  int rc;
> >  > +    Lisp_Object window = f->tab_bar_window;
> >  > +    struct window *w = XWINDOW (window);
> >  > +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
> >
> > The idea is that now that there's mouse-face support, people can
> customize a dedicated face for tab-bar
> > tabs.  This is in line with tab-line tabs and its highlight face.
>
> Sounds strange to me to have a face that no other code uses.  I would
> understand if this face was by default identical to the 'default'
> face, and was used by the tab bar.
>

I will ask Prot to theme this face in modus-themes so it will be used there.

[Message part 2 (text/html, inline)]

Message #65 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 21:08:34 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 28 Feb 2025 13:20:49 -0500
> Cc: juri <at> linkov.net, 76394 <at> debbugs.gnu.org
> 
> On Fri, Feb 28, 2025 at 1:06 PM Ship Mints <shipmints <at> gmail.com> wrote:
> 
>  Why does indention of the new code use 4 spaces, not 2?
> 
>  No idea.  The .dir-locals.el is in effect.  I checked several buffer locals to ensure that was true.  What
>  should I look at to help analyze this?  I suspect others will have this issue as well when helping with C
>  code.
> 
> My default c-basic-offset is 4.  .dir-locals.el is silent on that, so I get mine rather than yours.  Would you like
> me to update .dir.locals.el?  I will put a locals-2 with the correction, at least that will get me started.

.dir-locals.el sets the indentation style, but it doesn't attempt to
override every customization variable whose value is determined by the
style.

Message #68 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 14:09:51 -0500

[Message part 1 (text/plain, inline)]

Another patch rev attached.

On Fri, Feb 28, 2025 at 2:04 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Fri, Feb 28, 2025 at 2:00 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> >
>> > So we'll be super duper defensive, then.  Should I leave the "future"
>> code in place after the assertion or do
>> > you think it's easy enough to recreate if/when needed?
>>
>> I'd prefer to avoid testing for a condition that is always true.
>>
>
> I'll remove the code.  It's in the archive in older patches, if ever
> needed.
>
> >    * lisp/tab-bar.el (tab-bar-tab-highlight): New face.
>> >
>> > I'll update.
>> >
>> >  But I have a question: why add this face if there's no code that uses
>> >  it?  Or what did I miss?
>> >
>> >  > -  bool close_p;
>> >  > -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
>> >  > -  int rc;
>> >  > +    Lisp_Object window = f->tab_bar_window;
>> >  > +    struct window *w = XWINDOW (window);
>> >  > +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
>> >
>> > The idea is that now that there's mouse-face support, people can
>> customize a dedicated face for tab-bar
>> > tabs.  This is in line with tab-line tabs and its highlight face.
>>
>> Sounds strange to me to have a face that no other code uses.  I would
>> understand if this face was by default identical to the 'default'
>> face, and was used by the tab bar.
>>
>
> I will ask Prot to theme this face in modus-themes so it will be used
> there.
>

[Message part 2 (text/html, inline)]

[0001-mouse-face-properties-on-tab-bar-tab-captions-bug-76.patch (application/octet-stream, attachment)]

Message #71 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 14:15:19 -0500

[Message part 1 (text/plain, inline)]

On Fri, Feb 28, 2025 at 2:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

>
> > My default c-basic-offset is 4.  .dir-locals.el is silent on that, so I
> get mine rather than yours.  Would you like
> > me to update .dir.locals.el?  I will put a locals-2 with the correction,
> at least that will get me started.
>
> .dir-locals.el sets the indentation style, but it doesn't attempt to
> override every customization variable whose value is determined by the
> style.
>

It mystifies me why the dir-locals style does not override my default
c-basic-offset.  I looked at the cc-mode manual and a bit at the code, and
there's no mention that I saw of a value-determination hierarchy where a
global might override a style setting.  If there are any cc-mode experts
out there, perhaps they can chime in.

[Message part 2 (text/html, inline)]

Message #74 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 15:35:44 -0500

[Message part 1 (text/plain, inline)]

On Fri, Feb 28, 2025 at 2:09 PM Ship Mints <shipmints <at> gmail.com> wrote:

> Another patch rev attached.
>
> On Fri, Feb 28, 2025 at 2:04 PM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> On Fri, Feb 28, 2025 at 2:00 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>> >
>>> > So we'll be super duper defensive, then.  Should I leave the "future"
>>> code in place after the assertion or do
>>> > you think it's easy enough to recreate if/when needed?
>>>
>>> I'd prefer to avoid testing for a condition that is always true.
>>>
>>
>> I'll remove the code.  It's in the archive in older patches, if ever
>> needed.
>>
>> >    * lisp/tab-bar.el (tab-bar-tab-highlight): New face.
>>> >
>>> > I'll update.
>>> >
>>> >  But I have a question: why add this face if there's no code that uses
>>> >  it?  Or what did I miss?
>>> >
>>> >  > -  bool close_p;
>>> >  > -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
>>> >  > -  int rc;
>>> >  > +    Lisp_Object window = f->tab_bar_window;
>>> >  > +    struct window *w = XWINDOW (window);
>>> >  > +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
>>> >
>>> > The idea is that now that there's mouse-face support, people can
>>> customize a dedicated face for tab-bar
>>> > tabs.  This is in line with tab-line tabs and its highlight face.
>>>
>>> Sounds strange to me to have a face that no other code uses.  I would
>>> understand if this face was by default identical to the 'default'
>>> face, and was used by the tab bar.
>>>
>>
>> I will ask Prot to theme this face in modus-themes so it will be used
>> there.
>>
>
I will do two more things for the next patch.  I will add NEWS.  I will
also use the new face as the default mouse-face
in tab-bar-tab-name-format-face.  I suppose we could add
a tab-bar-tab-name-format-mouse-face function to
the tab-bar-tab-name-format-functions list.  What do you/Juri think?

[Message part 2 (text/html, inline)]

Message #77 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Fri, 28 Feb 2025 16:43:46 -0500

[Message part 1 (text/plain, inline)]

It seemed natural to add tab-bar-tab-name-format-mouse-face function to
the tab-bar-tab-name-format-functions list.  See attached.

-Stephane

On Fri, Feb 28, 2025 at 3:35 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Fri, Feb 28, 2025 at 2:09 PM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> Another patch rev attached.
>>
>> On Fri, Feb 28, 2025 at 2:04 PM Ship Mints <shipmints <at> gmail.com> wrote:
>>
>>> On Fri, Feb 28, 2025 at 2:00 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>
>>>> >
>>>> > So we'll be super duper defensive, then.  Should I leave the "future"
>>>> code in place after the assertion or do
>>>> > you think it's easy enough to recreate if/when needed?
>>>>
>>>> I'd prefer to avoid testing for a condition that is always true.
>>>>
>>>
>>> I'll remove the code.  It's in the archive in older patches, if ever
>>> needed.
>>>
>>> >    * lisp/tab-bar.el (tab-bar-tab-highlight): New face.
>>>> >
>>>> > I'll update.
>>>> >
>>>> >  But I have a question: why add this face if there's no code that uses
>>>> >  it?  Or what did I miss?
>>>> >
>>>> >  > -  bool close_p;
>>>> >  > -  enum draw_glyphs_face draw = DRAW_IMAGE_RAISED;
>>>> >  > -  int rc;
>>>> >  > +    Lisp_Object window = f->tab_bar_window;
>>>> >  > +    struct window *w = XWINDOW (window);
>>>> >  > +    Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
>>>> >
>>>> > The idea is that now that there's mouse-face support, people can
>>>> customize a dedicated face for tab-bar
>>>> > tabs.  This is in line with tab-line tabs and its highlight face.
>>>>
>>>> Sounds strange to me to have a face that no other code uses.  I would
>>>> understand if this face was by default identical to the 'default'
>>>> face, and was used by the tab bar.
>>>>
>>>
>>> I will ask Prot to theme this face in modus-themes so it will be used
>>> there.
>>>
>>
> I will do two more things for the next patch.  I will add NEWS.  I will
> also use the new face as the default mouse-face
> in tab-bar-tab-name-format-face.  I suppose we could add
> a tab-bar-tab-name-format-mouse-face function to
> the tab-bar-tab-name-format-functions list.  What do you/Juri think?
>

[Message part 2 (text/html, inline)]

[0001-mouse-face-properties-on-tab-bar-tab-captions-bug-76.patch (application/octet-stream, attachment)]

Message #80 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Sat, 01 Mar 2025 10:19:25 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 28 Feb 2025 15:35:44 -0500
> Cc: juri <at> linkov.net, 76394 <at> debbugs.gnu.org
> 
> I will do two more things for the next patch.  I will add NEWS.  I will also use the new face as the default
> mouse-face in tab-bar-tab-name-format-face.  I suppose we could add a
> tab-bar-tab-name-format-mouse-face function to the tab-bar-tab-name-format-functions list.  What do
> you/Juri think?

Good ideas, both of them, IMO.

Thanks.

Message #83 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76394 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Sat, 01 Mar 2025 10:33:56 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 28 Feb 2025 16:43:46 -0500
> Cc: juri <at> linkov.net, 76394 <at> debbugs.gnu.org
> 
> +(defface tab-bar-tab-highlight
> +  '((t :inherit highlight))
> +  "Tab bar face for highlighting."

IMO, the doc string should say that this face is used as mouse-face
on tab-bar buttons.

> +---
> +*** 'mouse-face' properties are now supported on the 'tab-bar'.
> +The new face 'tab-bar-tab-highlight' is applied as the 'mouse-face' on
> +each tab.
> +

And this NEWS entry should also say that tab-bar buttons are now
highlighted by default when the mouse pointer hovers of them, and that
to control that users can customize this new face.

Thanks.

Message #88 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Sun, 02 Mar 2025 19:15:08 +0200

> It seemed natural to add tab-bar-tab-name-format-mouse-face function to the
> tab-bar-tab-name-format-functions list.  See attached.

Thanks, I've tested your patch, and it works great!

> +(defface tab-bar-tab-highlight
> +  '((t :inherit highlight))
> +  "Tab bar face for highlighting."
> +  :version "31.1"
> +  :group 'tab-bar-faces)

Please use exactly the same style as in 'tab-line-highlight'.

> +(defun tab-bar-tab-name-format-mouse-face (name tab _i)

The arg 'tab' needs an underscore since compilation gives the
warning: Unused lexical argument `tab'.

> +      /* display_tab_bar does not yet support R2L.  */
> +      eassert (row->reversed_p);

Is this still needed?

Message #91 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Sun, 2 Mar 2025 14:37:02 -0500

[Message part 1 (text/plain, inline)]

On Sun, Mar 2, 2025 at 12:52 PM Juri Linkov <juri <at> linkov.net> wrote:

> > It seemed natural to add tab-bar-tab-name-format-mouse-face function to
> the
> > tab-bar-tab-name-format-functions list.  See attached.
>
> Thanks, I've tested your patch, and it works great!
>
> > +(defface tab-bar-tab-highlight
> > +  '((t :inherit highlight))
> > +  "Tab bar face for highlighting."
> > +  :version "31.1"
> > +  :group 'tab-bar-faces)
>
> Please use exactly the same style as in 'tab-line-highlight'.
>

Done.

> +(defun tab-bar-tab-name-format-mouse-face (name tab _i)
>
> The arg 'tab' needs an underscore since compilation gives the
> warning: Unused lexical argument `tab'.
>

Done.  I almost always run the byte compiler to check my changes but
neglected this time.

> +      /* display_tab_bar does not yet support R2L.  */
> > +      eassert (row->reversed_p);
>
> Is this still needed?
>

Eli asked for that.

While we're at this, should we implement the equivalent of
tab-line-close-highlight in tab-bar?  I can do that before I share the next
patch.

[Message part 2 (text/html, inline)]

Message #94 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Sun, 2 Mar 2025 16:06:40 -0500

[Message part 1 (text/plain, inline)]

On Sun, Mar 2, 2025 at 2:37 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Sun, Mar 2, 2025 at 12:52 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > It seemed natural to add tab-bar-tab-name-format-mouse-face function to
>> the
>> > tab-bar-tab-name-format-functions list.  See attached.
>>
>> Thanks, I've tested your patch, and it works great!
>>
>> > +(defface tab-bar-tab-highlight
>> > +  '((t :inherit highlight))
>> > +  "Tab bar face for highlighting."
>> > +  :version "31.1"
>> > +  :group 'tab-bar-faces)
>>
>> Please use exactly the same style as in 'tab-line-highlight'.
>>
>
> Done.
>
> > +(defun tab-bar-tab-name-format-mouse-face (name tab _i)
>>
>> The arg 'tab' needs an underscore since compilation gives the
>> warning: Unused lexical argument `tab'.
>>
>
> Done.  I almost always run the byte compiler to check my changes but
> neglected this time.
>
> > +      /* display_tab_bar does not yet support R2L.  */
>> > +      eassert (row->reversed_p);
>>
>> Is this still needed?
>>
>
> Eli asked for that.
>
> While we're at this, should we implement the equivalent of
> tab-line-close-highlight in tab-bar?  I can do that before I share the next
> patch.
>

I went ahead and mousified the close buttons, too, like tab-line does.

Revised patch attached with revised NEWS for both new faces.

[Message part 2 (text/html, inline)]

[0001-mouse-face-properties-on-tab-bar-tab-captions-bug-76.patch (application/octet-stream, attachment)]

Message #97 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 03 Mar 2025 09:42:52 +0200

>     While we're at this, should we implement the equivalent of
>     tab-line-close-highlight in tab-bar?  I can do that before I share the
>     next patch.
>
> I went ahead and mousified the close buttons, too, like tab-line does.

Sorry, the close buttons now look horrible.

Could you try to keep the previous style that
slightly raised the close button's border on hover?

Message #100 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: shipmints <at> gmail.com, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 03 Mar 2025 14:29:30 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76394 <at> debbugs.gnu.org
> Date: Sun, 02 Mar 2025 19:15:08 +0200
> 
> > +      /* display_tab_bar does not yet support R2L.  */
> > +      eassert (row->reversed_p);
> 
> Is this still needed?

It should be the other way around:

  eassert (!row->reversed_p);

Message #103 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 3 Mar 2025 07:38:36 -0500

[Message part 1 (text/plain, inline)]

On macOS it looks nice.  I'll fire up and freshen my Linux/GTK virtual
machine and look there.

On Mon, Mar 3, 2025 at 2:44 AM Juri Linkov <juri <at> linkov.net> wrote:

> >     While we're at this, should we implement the equivalent of
> >     tab-line-close-highlight in tab-bar?  I can do that before I share
> the
> >     next patch.
> >
> > I went ahead and mousified the close buttons, too, like tab-line does.
>
> Sorry, the close buttons now look horrible.
>
> Could you try to keep the previous style that
> slightly raised the close button's border on hover?
>

[Message part 2 (text/html, inline)]

Message #106 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76394 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 3 Mar 2025 07:39:18 -0500

[Message part 1 (text/plain, inline)]

Indeed.  I am no longer running with a debug build so didn't find that.  It
would have been an immediate boom.

On Mon, Mar 3, 2025 at 7:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Juri Linkov <juri <at> linkov.net>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,  76394 <at> debbugs.gnu.org
> > Date: Sun, 02 Mar 2025 19:15:08 +0200
> >
> > > +      /* display_tab_bar does not yet support R2L.  */
> > > +      eassert (row->reversed_p);
> >
> > Is this still needed?
>
> It should be the other way around:
>
>   eassert (!row->reversed_p);
>

[Message part 2 (text/html, inline)]

Message #109 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 3 Mar 2025 12:51:08 -0500

[Message part 1 (text/plain, inline)]

Try this.  Nothing looks horrible to me on either macOS or Linux/GTK.  If
you still don't like it, would you send a screenshot so I understand what
you're seeing?

-Stephane

On Mon, Mar 3, 2025 at 2:44 AM Juri Linkov <juri <at> linkov.net> wrote:

> >     While we're at this, should we implement the equivalent of
> >     tab-line-close-highlight in tab-bar?  I can do that before I share
> the
> >     next patch.
> >
> > I went ahead and mousified the close buttons, too, like tab-line does.
>
> Sorry, the close buttons now look horrible.
>
> Could you try to keep the previous style that
> slightly raised the close button's border on hover?
>

[Message part 2 (text/html, inline)]

[0001-mouse-face-properties-on-tab-bar-tab-captions-bug-76.patch (application/octet-stream, attachment)]

Message #112 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 03 Mar 2025 20:22:44 +0200

[Message part 1 (text/plain, inline)]

> Try this.  Nothing looks horrible to me on either macOS or Linux/GTK.  If
> you still don't like it, would you send a screenshot so I understand what
> you're seeing?

Before:

[before.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

After:

[after.png (image/png, inline)]

Message #115 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 3 Mar 2025 13:25:03 -0500

[Message part 1 (text/plain, inline)]

Even with the latest patch? I put a nice box in there.

On Mon, Mar 3, 2025 at 1:23 PM Juri Linkov <juri <at> linkov.net> wrote:

> > Try this.  Nothing looks horrible to me on either macOS or Linux/GTK.  If
> > you still don't like it, would you send a screenshot so I understand what
> > you're seeing?
>
> Before:
>
> After:
>

[Message part 2 (text/html, inline)]

Message #118 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 03 Mar 2025 20:41:09 +0200

> Even with the latest patch? I put a nice box in there.

Now it's your turn to show the screenshot.

Message #121 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 3 Mar 2025 14:00:32 -0500

[Message part 1 (text/plain, inline)]

Obv, this is -Q...

[image: image.png]

[image: image.png]

On Mon, Mar 3, 2025 at 1:42 PM Juri Linkov <juri <at> linkov.net> wrote:

> > Even with the latest patch? I put a nice box in there.
>
> Now it's your turn to show the screenshot.
>

[Message part 2 (text/html, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

Message #124 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 3 Mar 2025 14:03:34 -0500

[Message part 1 (text/plain, inline)]

Are you reacting to that now the button is no longer sharing the face of
the main part of the tab?  I prefer it outside the main caption, it offers
easier visual differentiation.

On Mon, Mar 3, 2025 at 2:00 PM Ship Mints <shipmints <at> gmail.com> wrote:

> Obv, this is -Q...
>
> [image: image.png]
>
> [image: image.png]
>
> On Mon, Mar 3, 2025 at 1:42 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > Even with the latest patch? I put a nice box in there.
>>
>> Now it's your turn to show the screenshot.
>>
>

[Message part 2 (text/html, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

Message #127 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Mon, 3 Mar 2025 20:40:21 -0500

[Message part 1 (text/plain, inline)]

And GTK...

[image: image.png]
[image: image.png]

P.S. There's a typo in one of the new faces I'll take care of in the
iteration of the patch.

On Mon, Mar 3, 2025 at 2:00 PM Ship Mints <shipmints <at> gmail.com> wrote:

> Obv, this is -Q...
>
> [image: image.png]
>
> [image: image.png]
>
> On Mon, Mar 3, 2025 at 1:42 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > Even with the latest patch? I put a nice box in there.
>>
>> Now it's your turn to show the screenshot.
>>
>

[Message part 2 (text/html, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

Message #130 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Tue, 04 Mar 2025 09:04:24 +0200

> Are you reacting to that now the button is no longer sharing the face of
> the main part of the tab?  I prefer it outside the main caption, it offers
> easier visual differentiation.

Now the close button is not part of the tab :-(

Message #133 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Tue, 4 Mar 2025 06:04:01 -0500

[Message part 1 (text/plain, inline)]

On Tue, Mar 4, 2025 at 2:13 AM Juri Linkov <juri <at> linkov.net> wrote:

> > Are you reacting to that now the button is no longer sharing the face of
> > the main part of the tab?  I prefer it outside the main caption, it
> offers
> > easier visual differentiation.
>
> Now the close button is not part of the tab :-(
>

I'll play with it more and see what I can come up with that satisfies us
both.

[Message part 2 (text/html, inline)]

Message #136 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Tue, 4 Mar 2025 08:30:59 -0500

[Message part 1 (text/plain, inline)]

On Tue, Mar 4, 2025 at 6:04 AM Ship Mints <shipmints <at> gmail.com> wrote:

> On Tue, Mar 4, 2025 at 2:13 AM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > Are you reacting to that now the button is no longer sharing the face of
>> > the main part of the tab?  I prefer it outside the main caption, it
>> offers
>> > easier visual differentiation.
>>
>> Now the close button is not part of the tab :-(
>>
>
> I'll play with it more and see what I can come up with that satisfies us
> both.
>

Given that text properties don't nest, I matched the faces and use separate
mouse-face properties for each component so they could be highlighted
separately.  Look at the attached screenshots.  You still might not like
it.  I also handled the case where the close button might be text only vs.
icon so it works for both.

[image: image.png]
[image: image.png]
[image: image.png]
[image: image.png]

[Message part 2 (text/html, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

[image.png (image/png, inline)]

Message #139 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Wed, 05 Mar 2025 09:50:10 +0200

> Given that text properties don't nest, I matched the faces and use separate
> mouse-face properties for each component so they could be highlighted
> separately.  Look at the attached screenshots.  You still might not like
> it.  I also handled the case where the close button might be text only vs.
> icon so it works for both.

Does using 'add-face-text-property' (like in 'tab-bar-tab-name-format-face')
instead of 'propertize' help to make the close button look like part of the tab?

Message #142 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Wed, 5 Mar 2025 10:19:48 -0500

[Message part 1 (text/plain, inline)]

On Wed, Mar 5, 2025 at 2:58 AM Juri Linkov <juri <at> linkov.net> wrote:

> > Given that text properties don't nest, I matched the faces and use
> separate
> > mouse-face properties for each component so they could be highlighted
> > separately.  Look at the attached screenshots.  You still might not like
> > it.  I also handled the case where the close button might be text only
> vs.
> > icon so it works for both.
>
> Does using 'add-face-text-property' (like in
> 'tab-bar-tab-name-format-face')
> instead of 'propertize' help to make the close button look like part of
> the tab?
>

Nope.  I think the issue is that the mouse-face on the caption left of the
close button cannot itself highlight the whole string while simultaneously
having a mouse-face on the close button.  So we either live with the visual
separation which appears only when people mouse over caption segments, or
abandon mouse-face on the close button.  I prefer the visual separation as
it makes it clear the close button is separate from the caption text.

[Message part 2 (text/html, inline)]

Message #145 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Wed, 05 Mar 2025 19:17:29 +0200

>     > Given that text properties don't nest, I matched the faces and use
>     separate
>     > mouse-face properties for each component so they could be highlighted
>     > separately.  Look at the attached screenshots.  You still might not
>     like
>     > it.  I also handled the case where the close button might be text
>     only vs.
>     > icon so it works for both.
>
>     Does using 'add-face-text-property' (like in
>     'tab-bar-tab-name-format-face')
>     instead of 'propertize' help to make the close button look like part of
>     the tab?
>
> Nope.  I think the issue is that the mouse-face on the caption left of the
> close button cannot itself highlight the whole string while simultaneously
> having a mouse-face on the close button.  So we either live with the visual
> separation which appears only when people mouse over caption segments, or
> abandon mouse-face on the close button.  I prefer the visual separation as
> it makes it clear the close button is separate from the caption text.

Unfortunately, the visual separation is too ugly.  But maybe
mouse-face on the close button is not needed, because hovering
over the close button already has visual indication in the form
of the raised button.

Message #148 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Wed, 5 Mar 2025 12:26:34 -0500

[Message part 1 (text/plain, inline)]

On Wed, Mar 5, 2025 at 12:23 PM Juri Linkov <juri <at> linkov.net> wrote:

> >     > Given that text properties don't nest, I matched the faces and use
> >     separate
> >     > mouse-face properties for each component so they could be
> highlighted
> >     > separately.  Look at the attached screenshots.  You still might not
> >     like
> >     > it.  I also handled the case where the close button might be text
> >     only vs.
> >     > icon so it works for both.
> >
> >     Does using 'add-face-text-property' (like in
> >     'tab-bar-tab-name-format-face')
> >     instead of 'propertize' help to make the close button look like part
> of
> >     the tab?
> >
> > Nope.  I think the issue is that the mouse-face on the caption left of
> the
> > close button cannot itself highlight the whole string while
> simultaneously
> > having a mouse-face on the close button.  So we either live with the
> visual
> > separation which appears only when people mouse over caption segments, or
> > abandon mouse-face on the close button.  I prefer the visual separation
> as
> > it makes it clear the close button is separate from the caption text.
>
> Unfortunately, the visual separation is too ugly.  But maybe
> mouse-face on the close button is not needed, because hovering
> over the close button already has visual indication in the form
> of the raised button.
>

That's so only when the button is an icon and not text.

At this stage, I say I'll remove the close button mouse face and resubmit
the patch.  We can enhance later and people can customize for themselves.
The formatting functions are very flexible.

[Message part 2 (text/html, inline)]

Message #151 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Wed, 5 Mar 2025 17:46:46 -0500

[Message part 1 (text/plain, inline)]

On Wed, Mar 5, 2025 at 12:26 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Wed, Mar 5, 2025 at 12:23 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> >     > Given that text properties don't nest, I matched the faces and use
>> >     separate
>> >     > mouse-face properties for each component so they could be
>> highlighted
>> >     > separately.  Look at the attached screenshots.  You still might
>> not
>> >     like
>> >     > it.  I also handled the case where the close button might be text
>> >     only vs.
>> >     > icon so it works for both.
>> >
>> >     Does using 'add-face-text-property' (like in
>> >     'tab-bar-tab-name-format-face')
>> >     instead of 'propertize' help to make the close button look like
>> part of
>> >     the tab?
>> >
>> > Nope.  I think the issue is that the mouse-face on the caption left of
>> the
>> > close button cannot itself highlight the whole string while
>> simultaneously
>> > having a mouse-face on the close button.  So we either live with the
>> visual
>> > separation which appears only when people mouse over caption segments,
>> or
>> > abandon mouse-face on the close button.  I prefer the visual separation
>> as
>> > it makes it clear the close button is separate from the caption text.
>>
>> Unfortunately, the visual separation is too ugly.  But maybe
>> mouse-face on the close button is not needed, because hovering
>> over the close button already has visual indication in the form
>> of the raised button.
>>
>
> That's so only when the button is an icon and not text.
>
> At this stage, I say I'll remove the close button mouse face and resubmit
> the patch.  We can enhance later and people can customize for themselves.
> The formatting functions are very flexible.
>

Patch attached.  Pretty much the same one as a few patches ago.

[Message part 2 (text/html, inline)]

[0001-mouse-face-properties-on-tab-bar-tab-captions-bug-76.patch (application/octet-stream, attachment)]

Message #154 received at 76394 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76394 <at> debbugs.gnu.org
Subject: Re: bug#76394: mouse-face property not working in tab-bar
Date: Thu, 06 Mar 2025 20:40:15 +0200

> Patch attached.  Pretty much the same one as a few patches ago.

Thanks!  Now pushed to master.  Let's keep this open
until we could find a solution for the close button
to change its borders on hover as defined by the
face style 'released-button'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.