Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User defined keybindings should take precedence over installed tools #660

Open
dented42 opened this issue Jan 18, 2024 · 1 comment
Open

Comments

@dented42
Copy link

Intuitively installed DrRacket tools/extensions should take precedence over the builtin defaults, and settings that the user specifies should take precedence over that. This doesn't seem to be the case with keybindings.

To replicate:
A fresh install of Racket 8.11.1, install the drracket-paredit package, and use the menu to add the following user defined keybinding file.

#lang s-exp framework/keybinding-lang

(keybinding "m:right"
            (λ (editor event)
              (send editor forward-sexp)))

(keybinding "m:left"
            (λ (editor event)
              (send editor backward-sexp)))

Restart DrRacket, and attempting to M-right and M-left your way around fails to jump across sexpressions. Instead drracket-paredits binding (which it calls forward-atom and backward-atom) is used instead.

It looks like the order in which things are getting loaded should be swapped.

@rfindler
Copy link
Member

rfindler commented Jan 18, 2024

In general, tools have access to lower-level APIs (in this case, overriding on-char or a related method) so it isn't always possible to have user-defined keymaps take precedence over what a tool is doing. In this case, however, the drracket-paredit tool seems to be using the same mechanism that DrRacket is using when DrRacket install's user's keybindings. That said, it looks to me like the order is already the one you want.

In detail, the call that install the user's keybindings is here, which calls keymap:add-user-keybindings-file and the tools are already installed by that point (you can verify by adding a printf there and one to the call in paredit to see that). Also, the latest call to add-keybindings-item is the one that wins because of the #t on this line in the call to chain-to-keymap in the body of keymap:add-user-keybindings-file.

It may be the case that "m:left" is not the keybinding that you think it is? In my tests, I used "s:left" and could see the overriding. The "m:left" keybinding is more complex because the meta prefix is more complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants