unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: 41343@debbugs.gnu.org, stefankangas@gmail.com
Subject: bug#41343: tab-bar-mode: Close tab on mouse-2 click
Date: Thu, 12 Aug 2021 11:43:59 +0300	[thread overview]
Message-ID: <83zgtncasw.fsf@gnu.org> (raw)
In-Reply-To: <87bl6384ow.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 12 Aug 2021 11:09:35 +0300)

> 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.





  reply	other threads:[~2021-08-12  8:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-17  4:05 bug#41343: tab-bar-mode: Close tab on mouse-2 click Stefan Kangas
2020-05-17 22:12 ` Juri Linkov
2020-05-17 22:23   ` Stefan Kangas
2020-05-18  2:32   ` Eli Zaretskii
2020-05-19 21:54     ` Juri Linkov
2020-05-20 15:59       ` Eli Zaretskii
2021-08-03 22:33 ` Juri Linkov
2021-08-04 11:32   ` Eli Zaretskii
2021-08-04 20:13     ` Juri Linkov
2021-08-05  5:43       ` Eli Zaretskii
2021-08-06  0:41         ` Juri Linkov
2021-08-06  6:26           ` Eli Zaretskii
2021-08-06  8:20             ` Juri Linkov
2021-08-06 12:38               ` Eli Zaretskii
2021-08-09  7:03                 ` Juri Linkov
2021-08-10 12:38                   ` Eli Zaretskii
2021-08-11  7:01                     ` Juri Linkov
2021-08-11 11:56                       ` Eli Zaretskii
2021-08-12  8:09                         ` Juri Linkov
2021-08-12  8:43                           ` Eli Zaretskii [this message]
2021-08-13  7:24                             ` Juri Linkov
2021-08-18 18:11                         ` Juri Linkov
2021-08-24 14:37                           ` Stefan Kangas
2021-09-05 17:18                             ` Juri Linkov
2021-09-06 19:40                               ` Stefan Kangas
2021-09-08 19:28                                 ` Juri Linkov
2021-09-08 21:18                                   ` Stefan Kangas
2021-09-14  6:43                                 ` Juri Linkov
2021-09-05 17:17                         ` Juri Linkov
2021-08-06 16:21           ` bug#41343: [External] : " Drew Adams
2021-08-09  7:06             ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zgtncasw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=41343@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).