racket / racket/drracket

User defined keybindings should take precedence over installed tools

Open
#660 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Racket
Stars
516
Forks
103
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the issue in DrRacket 8.11.1 with the drracket-paredit package and the shown user keybinding file using framework/keybinding-lang. Start by tracing how the user-defined and installed-tool bindings are loaded and ordered. Done means the user’s M-right and M-left bindings take precedence and jump across sexpressions.

Written by the indexing model from the issue text.

Assessment

Domain
desktop, devtools
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.