GNU bug report logs - #75918
[PATCH] Add new user option tab-bar-define-keys

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75918 in the body.
You can then email your comments to 75918 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Add new user option tab-bar-define-keys
Date: Tue, 28 Jan 2025 17:57:51 -0500

[Message part 1 (text/plain, inline)]

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

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.

-Stephane

[Message part 2 (text/html, inline)]

[0001-Add-new-user-option-tab-bar-define-keys.patch (application/octet-stream, attachment)]

Message #8 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 09:41:36 +0200

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

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

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)

Last but not least: have you signed FSF papers for your patches to be applied?

Message #11 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 06:51:57 -0500

[Message part 1 (text/plain, inline)]

On Wed, Jan 29, 2025 at 2:50 AM Juri Linkov <juri <at> linkov.net> wrote:

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

[Message part 2 (text/html, inline)]

Message #14 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75918 <at> debbugs.gnu.org, shipmints <at> gmail.com
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 14:44:37 +0200

> Cc: 75918 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 29 Jan 2025 09:41:36 +0200
> 
> Last but not least: have you signed FSF papers for your patches to be applied?

Yes, the assignment is on file.

Message #17 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 19:29:09 +0200

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

It checks for global-key-binding every time when the user types C-TAB.
So it could also check with local-key-binding and
minor-mode-key-binding in e.g. outline mode, etc.

But since you want to move the C-TAB keybinding from tab-bar-mode-map
back to tab-bar--define-keys, then :filter is not needed anymore,
so you can check for global-key-binding only once in tab-bar--define-keys.

Message #20 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 12:52:18 -0500

[Message part 1 (text/plain, inline)]

Right. How about I get rid of tab-bar-mode--tab-key-bind and just bind
normally? I'll submit a revised patch shortly, if so.

On Wed, Jan 29, 2025 at 12:35 PM Juri Linkov <juri <at> linkov.net> wrote:

> >>> 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.
>
> It checks for global-key-binding every time when the user types C-TAB.
> So it could also check with local-key-binding and
> minor-mode-key-binding in e.g. outline mode, etc.
>
> But since you want to move the C-TAB keybinding from tab-bar-mode-map
> back to tab-bar--define-keys, then :filter is not needed anymore,
> so you can check for global-key-binding only once in tab-bar--define-keys.
>

[Message part 2 (text/html, inline)]

Message #23 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 20:09:02 +0200

> Right. How about I get rid of tab-bar-mode--tab-key-bind and just bind
> normally? I'll submit a revised patch shortly, if so.

Yes, please do.

TIA.

>     >>> 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.
>
>     It checks for global-key-binding every time when the user types C-TAB.
>     So it could also check with local-key-binding and
>     minor-mode-key-binding in e.g. outline mode, etc.
>
>     But since you want to move the C-TAB keybinding from tab-bar-mode-map
>     back to tab-bar--define-keys, then :filter is not needed anymore,
>     so you can check for global-key-binding only once in
>     tab-bar--define-keys.

Message #26 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 13:45:28 -0500

[Message part 1 (text/plain, inline)]

Revised patch attached.

On Wed, Jan 29, 2025 at 1:09 PM Juri Linkov <juri <at> linkov.net> wrote:

> > Right. How about I get rid of tab-bar-mode--tab-key-bind and just bind
> > normally? I'll submit a revised patch shortly, if so.
>
> Yes, please do.
>
> TIA.
>
> >     >>> 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.
> >
> >     It checks for global-key-binding every time when the user types
> C-TAB.
> >     So it could also check with local-key-binding and
> >     minor-mode-key-binding in e.g. outline mode, etc.
> >
> >     But since you want to move the C-TAB keybinding from tab-bar-mode-map
> >     back to tab-bar--define-keys, then :filter is not needed anymore,
> >     so you can check for global-key-binding only once in
> >     tab-bar--define-keys.
>

[Message part 2 (text/html, inline)]

[0001-Add-new-user-option-tab-bar-define-keys.patch (application/octet-stream, attachment)]

Message #29 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 20:58:09 +0200

> +  (when (memq tab-bar-define-keys '(t tab))
> +    (define-key tab-bar-mode-map [(control tab)] #'tab-next)
> +    (define-key tab-bar-mode-map [(control shift tab)] #'tab-previous)
> +    (define-key tab-bar-mode-map [(control shift iso-lefttab)] #'tab-previous))

But we still need to check with global-key-binding here
before binding TAB keys.  This will ensure backwards-compatibility.

> -(defun tab-bar-mode--tab-key-bind (map key binding)
> -  ;; Don't override user customized global key bindings
> -  (define-key map key
> -    `(menu-item "" ,binding
> -      :filter ,(lambda (cmd) (unless (global-key-binding key) cmd)))))

Message #32 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Wed, 29 Jan 2025 14:28:29 -0500

[Message part 1 (text/plain, inline)]

This one should adequately address that backward compatibility issue.
Thanks for pointing it out.

On Wed, Jan 29, 2025 at 1:58 PM Juri Linkov <juri <at> linkov.net> wrote:

> > +  (when (memq tab-bar-define-keys '(t tab))
> > +    (define-key tab-bar-mode-map [(control tab)] #'tab-next)
> > +    (define-key tab-bar-mode-map [(control shift tab)] #'tab-previous)
> > +    (define-key tab-bar-mode-map [(control shift iso-lefttab)]
> #'tab-previous))
>
> But we still need to check with global-key-binding here
> before binding TAB keys.  This will ensure backwards-compatibility.
>
> > -(defun tab-bar-mode--tab-key-bind (map key binding)
> > -  ;; Don't override user customized global key bindings
> > -  (define-key map key
> > -    `(menu-item "" ,binding
> > -      :filter ,(lambda (cmd) (unless (global-key-binding key) cmd)))))
>

[Message part 2 (text/html, inline)]

[0001-Add-new-user-option-tab-bar-define-keys.patch (application/octet-stream, attachment)]

Message #35 received at 75918 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75918 <at> debbugs.gnu.org
Subject: Re: bug#75918: [PATCH] Add new user option tab-bar-define-keys
Date: Thu, 30 Jan 2025 20:33:49 +0200

close 75918 31.0.50
thanks

> This one should adequately address that backward compatibility issue.
> Thanks for pointing it out.

Thanks for the changes, now pushed and closed.

Previous Next

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