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

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefankangas <at> gmail.com>

Date: Sun, 17 May 2020 04:06:02 UTC

Severity: wishlist

Tags: fixed, patch

Merged with 41342

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 41343 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: bug#41343: tab-bar-mode: Close tab on mouse-2 click
Date: Fri, 06 Aug 2021 15:38:32 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: stefankangas <at> gmail.com,  41343 <at> debbugs.gnu.org
> Date: Fri, 06 Aug 2021 11:20:29 +0300
> 
> >> It's too late to change how keys are implemented for tab-bar.
> >> The tab-bar keymap contains such keys as 'tab-1' and 'C-tab-2',
> >> and clicking mouse-1 on tabs emits such events.  It doesn't emit
> >> 'mouse-1' and 'mouse-2'.
> >
> > How do we translate mouse clicks into the likes of C-tab-2?
> 
> When mouse-1 is clicked on the close button, then the
> Control modifier 'C-' is added to the menu-item symbol tab-2
> emitted as an event.

Are you talking about handle_tab_bar_click and the processing of
TAB_BAR_EVENT in make_lispy_event?  Or are there other/additional
parts to this processing?

IOW, where are the symbols like tab-2 produced?

> > And what prevents us from emitting something like tab-close-2 when
> > mouse-2 is clicked?
> 
> Then mouse-2 is still hard-coded and tab-close-2 is not much different
> from the previous patch that emits C-tab-2.
> 
> Or in "tab-close-2" what does "2" mean: the button number 2 (mouse-2),
> or the tab number 2 (tab-2)?
> 
> Should they then cover all combinations?  tab-1-mouse-1,
> tab-1-mouse-2, tab-2-mouse-1, tab-2-mouse-2, ...

I don't know, I don't think I have a clear idea of how these symbols
are produced yet, and you didn't tell enough for me to get such a
clear idea.  Please tell more details, so that this discussion could
be more efficient.

> >> It should be possible to implement normal key bindings mouse-1/mouse-2,
> >> but such change will not be backward-compatible.
> >
> > In what way will it be incompatible?
> 
> Currently tab-bar-make-keymap returns a keymap with menu-items.
> This is like menu-bar is implemented.  The menu-bar displays
> menu-items, and clicking on them emits events with their symbols.
> The tool-bar is implemented the same way: it displays
> menu-items, and clicking emits their symbols.
> The tab-bar is exactly the same: displays menu-items
> on the tab-bar, and clicking mouse-1 emits events
> with tab names, e.g. tab-2.
> 
> Users already are using such add-advice that expect
> tab-bar-make-keymap returning a keymap with menu-items.

If we find a way to produce a different symbol when mouse-2 is clicked
on a tab, there will be no incompatibility, right?




This bug report was last modified 3 years and 252 days ago.

Previous Next


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