From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41343: tab-bar-mode: Close tab on mouse-2 click Date: Thu, 12 Aug 2021 11:43:59 +0300 Message-ID: <83zgtncasw.fsf@gnu.org> References: <87wnp2cg52.fsf@linkov.net> <83tuk5la2u.fsf@gnu.org> <877dh18lj3.fsf@mail.linkov.net> <83y29gjvjh.fsf@gnu.org> <8735rn8jz6.fsf@mail.linkov.net> <83sfznhywm.fsf@gnu.org> <87tuk356ia.fsf@mail.linkov.net> <83im0iiw8n.fsf@gnu.org> <877dgvkt1z.fsf@mail.linkov.net> <83wnotfpak.fsf@gnu.org> <87k0ksecbq.fsf@mail.linkov.net> <83v94cdwk5.fsf@gnu.org> <87bl6384ow.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25152"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41343@debbugs.gnu.org, stefankangas@gmail.com To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 12 10:46:32 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mE6MC-0006Gu-6t for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Aug 2021 10:46:32 +0200 Original-Received: from localhost ([::1]:49974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mE6MB-0007Gz-9L for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Aug 2021 04:46:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36184) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mE6Kl-0003jh-Tc for bug-gnu-emacs@gnu.org; Thu, 12 Aug 2021 04:45:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54205) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mE6Kl-0007FF-Jz for bug-gnu-emacs@gnu.org; Thu, 12 Aug 2021 04:45:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mE6Kk-0000Kc-FR for bug-gnu-emacs@gnu.org; Thu, 12 Aug 2021 04:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Aug 2021 08:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41343 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 41343-submit@debbugs.gnu.org id=B41343.16287578651217 (code B ref 41343); Thu, 12 Aug 2021 08:45:02 +0000 Original-Received: (at 41343) by debbugs.gnu.org; 12 Aug 2021 08:44:25 +0000 Original-Received: from localhost ([127.0.0.1]:37518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE6K8-0000JZ-R0 for submit@debbugs.gnu.org; Thu, 12 Aug 2021 04:44:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE6K6-0000JL-FL for 41343@debbugs.gnu.org; Thu, 12 Aug 2021 04:44:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60046) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mE6K0-0006XC-N4; Thu, 12 Aug 2021 04:44:16 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2247 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mE6K0-0000FL-AJ; Thu, 12 Aug 2021 04:44:16 -0400 In-Reply-To: <87bl6384ow.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 12 Aug 2021 11:09:35 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211653 Archived-At: > From: Juri Linkov > 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: > > (# tab-line (30 . 10) 29999999 > (#(" buffer.el x" 1 10 (tab #)) . 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.