bug#41343: tab-bar-mode: Close tab on mouse-2 click

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: stefankangas@gmail.com,  41343@debbugs.gnu.org
> Date: Thu, 12 Aug 2021 11:09:35 +0300
> 
> Events emitted on the tab-line contain the tab caption
> with text properties that help to identify the clicked tab:
> 
>  (#<window 391 on buffer.el> tab-line (30 . 10) 29999999
>   (#(" buffer.el x" 1 10 (tab #<buffer buffer.el>)) . 4)
> 
> The tab-bar could do the same, but how to support existing code
> that doesn't add text properties to the tab-bar tab captions
> in the tab-bar-format function?

Hmm... I cannot find a function named tab-bar-format, so I don't think
I understand the question.  In general, if existing code doesn't add
some text properties, how can that be a problem?

> This means that text properties identifying the clicked tab
> should be added to the tab caption only after clicking
> in the emitted event.  But then the problem that the added
> text properties might conflict with the existing text properties
> added in the tab-bar-format function.
> 
> For example, the tab-bar-format function puts the text property
> 'close-tab' on the close button.  If the emitted event
> will add another property with the same name 'close-tab'
> to indicate whether the close button was clicked, it might overwrite
> the existing text property on the tab caption.  Maybe then
> add the property only on the first character, on the assumption
> that it would be less likely to overwrite the existing property.

If you use property names that are unlikely to conflict, I see no
problem here.  These are special properties used by Emacs for internal
needs of handling the tab bar, so we can use any name that suits us.
And since all of the property names are produced by Emacs itself, we
can easily enough have a set of names without conflicts.  Right?  Or
what am I missing?

> IOW, with the existing event format, the only way to add event metadata
> is to stuff more text properties on the tab caption that already
> contains some text properties, such as tab face, and properties
> denoting the close button.  But how to do this in a non-conflicting way?

I don't think the problem is severe, see above.

Alternatively, we could introduce a new format for OBJECT, but then
we'd need to document it, and try to make sure it won't cause
compatibility problems in existing code.  I think this is a more
complicated alternative, so my recommendation is to try to deconflict
the properties.