> This controls which key bindings tab-bar creates. Values are t,the
> default, which defines all keys and is backwards compatible, 'numeric
> (tab number selection only), 'tab (TAB and SHIFT-TAB keys only), nil
> (which defines none).
Thanks for the patch. I don't understand why to add 'numeric' when
it's already customized by 'tab-bar-select-tab-modifiers'.
If the problem is only with tab keys then a better name
would be 'tab-bar-tab-keys'.
I think it's a clearer way to control key definitions than relying on tab-bar-select-tab-modifiers, which has a separate impact that just so happens to be used as a numeric definition toggle.
> This is useful to avoid key binding conflicts, such as when folding in
> outline mode using TAB keys, or when a user wants to define her own
> tab-bar keys without first having to remove the defaults.
The current implementation was intended to allow removing the default keys
easily from 'tab-bar-mode-map'. Here is the NEWS from bug#69578:
*** New keymap 'tab-bar-mode-map'.
By default it contains a keybinding 'C-TAB' to switch tabs, but only
when 'C-TAB' is not bound globally. You can unbind it if it conflicts
with 'C-TAB' in other modes.
This strategy doesn't account for the key definition race condition, and relies on the user to have first defined global TAB keys before tab-bar-mode is enabled.
Is the new option intended only to replace in config files:
(define-key tab-bar-mode-map [(control tab)] nil t)
with
(setopt tab-bar-define-keys nil)
Or (setopt tab-bar-define-keys 'numeric) which is what I will use and I will remove some accumulated init cruft.
Last but not least: have you signed FSF papers for your patches to be applied?
Paperwork is on file.
-Stephane