bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#69578: 30.0.50; tab-bar-mode binding of (control tab) not always use


From: Jonas Bernoulli
Subject: bug#69578: 30.0.50; tab-bar-mode binding of (control tab) not always useful
Date: Mon, 11 Mar 2024 15:23:51 +0100

> The developers of Org mode took courage and replaced their C-TAB
> bindings with C-c C-TAB:

It indeed takes courage to change key bindings; there will always be
a few users who get very upset by such a change.

> These bindings stop taking effect if a mode has its own bindings for
> control tab, for instance. A prominent example is Magit.

I have addressed this in Magit as described in this commit message:

magit-section-cycle: Pivot to tab-next if there is a binding conflict

If `tab-bar-mode' is enable, then "C-<tab>" is bound to `tab-next'
in the global map.  That conflicts with our local (and much older)
binding for `magit-section-cycle'.

Address this conflict by teaching `magit-section-cycle' to pivot to
`tab-next', but only if `tab-bar-mode' is enabled.  That way, users
who do not use `tab-bar-mode' (i.e., the majority), are not affected
by this unfortunate conflict.

`tab-bar-mode' users will have to get used to the much less convenient
"C-c TAB" binding to cycle section visibility.  Alternatively they can
advice `tab-bar--define-keys' to bind another key to `tab-next'.  It
would be nice if `tab-bar-mode', instead of modifying the global map,
used a mode map, and thus didn't make it so very hard to change its
key bindings.

> So, maybe these bindings should not be done?

Too late for that now, but they should definitely be done in a way that
users can customize, without having to advice tab-bar--define-keys (and
tab-bar--undefine-keys).  Maybe by using a mode map?  If there is some
reason this cannot be done, then maybe a "dummy keymap" could be used?
(User could then manipulate the fake tab-bar-mode-map like any keymap,
but the bindings it contains would then somehow be "transplanted" into
the global map by tab-bar--define-keys.)

>> Thanks, should we therefore close this bug?
>
> I'll close it in a second, thanks.

This seems premature, making it so hard for users to change the tab-bar
bindings seems like something that needs to be fixed.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]