GNU bug report logs - #79526
30.2.50; Invasive keybinding in vtable-map

Previous Next

To reply to this bug, email your comments to 79526 AT debbugs.gnu.org.

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

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2.50; Invasive keybinding in vtable-map
Date: Sun, 28 Sep 2025 10:26:51 +0200

`vtable-map' is used as a keymap text property and therefore takes very
high precedence and can conflict with user customization (even if the
user employs the usual workarounds such as placing customizations in a
minor mode map instead of the global keymap).

I have no issue with the definitions in `vtable-map' that override a
self-inserting key, but M-left and M-right are quite likely to create
clashes.  Also, AFAIK those keys don't work in the terminal.

Therefore I would suggest replacing M-left and M-right with ( and ) or [
and ].  The latter might be a good candidate for some kind of page
navigation command so I'd have a preference for the first option.
(There might be a precedent in other packages for that kind of command
that we could follow here, but I'm not aware of it.)

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 79526 <at> debbugs.gnu.org
Subject: Re: bug#79526: 30.2.50; Invasive keybinding in vtable-map
Date: Sun, 28 Sep 2025 09:12:09 -0400

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

On Sun, Sep 28, 2025 at 4:28 AM Augusto Stoffel <arstoffel <at> gmail.com> wrote:

> `vtable-map' is used as a keymap text property and therefore takes very
> high precedence and can conflict with user customization (even if the
> user employs the usual workarounds such as placing customizations in a
> minor mode map instead of the global keymap).
>
> I have no issue with the definitions in `vtable-map' that override a
> self-inserting key, but M-left and M-right are quite likely to create
> clashes.  Also, AFAIK those keys don't work in the terminal.
>
> Therefore I would suggest replacing M-left and M-right with ( and ) or [
> and ].  The latter might be a good candidate for some kind of page
> navigation command so I'd have a preference for the first option.
> (There might be a precedent in other packages for that kind of command
> that we could follow here, but I'm not aware of it.)
>

[Still painfully one handed...]

All keymaps are invasive, those are just likely more annoying than the
others.  How about we make assigning the default keymap optional and users
would specify the `:keymap` keyword to provide whatever preferred
mappings?  (I'm sure Lars didn't expect anyone clever enough to insert a
vtable in a comint buffer...)

-Stéphane

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

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 79526 <at> debbugs.gnu.org,
 Augusto Stoffel <arstoffel <at> gmail.com>
Subject: Re: bug#79526: 30.2.50; Invasive keybinding in vtable-map
Date: Wed, 01 Oct 2025 13:43:55 +0200

On Sun, 28 Sep 2025 at 09:12, Stéphane Marks wrote:

> On Sun, Sep 28, 2025 at 4:28 AM Augusto Stoffel <arstoffel <at> gmail.com> wrote:
>
>  `vtable-map' is used as a keymap text property and therefore takes very
>  high precedence and can conflict with user customization (even if the
>  user employs the usual workarounds such as placing customizations in a
>  minor mode map instead of the global keymap).
>
>  I have no issue with the definitions in `vtable-map' that override a
>  self-inserting key, but M-left and M-right are quite likely to create
>  clashes.  Also, AFAIK those keys don't work in the terminal.
>
>  Therefore I would suggest replacing M-left and M-right with ( and ) or [
>  and ].  The latter might be a good candidate for some kind of page
>  navigation command so I'd have a preference for the first option.
>  (There might be a precedent in other packages for that kind of command
>  that we could follow here, but I'm not aware of it.)
>
> [Still painfully one handed...]
>
> All keymaps are invasive, those are just likely more annoying than the others.  How
> about we make assigning the default keymap optional and users would specify the
> `:keymap` keyword to provide whatever preferred mappings?

Not sure I follow.  By "user" I meant the end user, not the developer
using vtable.el.  And my point is that M-<left> / M-<right> on a text
property keymap is highly likely to cause conflicts.

Maybe you're referring to the fact that vtable "conveniently" adds
`vtable-map' as a parent of the supplied :keymap?  I think that's indeed
not a good approach and could be changed.  The package author should
have the flexibility do decide and it's trivial to define a keymap with
a parent.

> (I'm sure Lars didn't expect anyone clever enough to insert a vtable
> in a comint buffer...)

I think this was totally intended.  The manual touts the fact you can
have a vtable as part of arbitrary buffers :-).

> -Stéphane 

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 79526 <at> debbugs.gnu.org
Subject: Re: bug#79526: 30.2.50; Invasive keybinding in vtable-map
Date: Wed, 1 Oct 2025 07:57:02 -0400

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

On Wed, Oct 1, 2025 at 7:43 AM Augusto Stoffel <arstoffel <at> gmail.com> wrote:

> On Sun, 28 Sep 2025 at 09:12, Stéphane Marks wrote:
>
> > On Sun, Sep 28, 2025 at 4:28 AM Augusto Stoffel <arstoffel <at> gmail.com>
> wrote:
> >
> >  `vtable-map' is used as a keymap text property and therefore takes very
> >  high precedence and can conflict with user customization (even if the
> >  user employs the usual workarounds such as placing customizations in a
> >  minor mode map instead of the global keymap).
> >
> >  I have no issue with the definitions in `vtable-map' that override a
> >  self-inserting key, but M-left and M-right are quite likely to create
> >  clashes.  Also, AFAIK those keys don't work in the terminal.
> >
> >  Therefore I would suggest replacing M-left and M-right with ( and ) or [
> >  and ].  The latter might be a good candidate for some kind of page
> >  navigation command so I'd have a preference for the first option.
> >  (There might be a precedent in other packages for that kind of command
> >  that we could follow here, but I'm not aware of it.)
> >
> > [Still painfully one handed...]
> >
> > All keymaps are invasive, those are just likely more annoying than the
> others.  How
> > about we make assigning the default keymap optional and users would
> specify the
> > `:keymap` keyword to provide whatever preferred mappings?
>
> Not sure I follow.  By "user" I meant the end user, not the developer
> using vtable.el.  And my point is that M-<left> / M-<right> on a text
> property keymap is highly likely to cause conflicts.
>
> Maybe you're referring to the fact that vtable "conveniently" adds
> `vtable-map' as a parent of the supplied :keymap?  I think that's indeed
> not a good approach and could be changed.  The package author should
> have the flexibility do decide and it's trivial to define a keymap with
> a parent.
>

Yes, indeed, I meant the vtable developer/user, not the end user.  I have
an extended "navigation" keymap option in a future patch (coming soon when
I can type normally again after my splint and bandages are gone, puts a
crimp in everything!) and I'll propose a refinement to keymap handling.

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

Previous Next

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