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