Overlap between R shortcuts / keybindings and positron ones

[EmilHvitfeldt]

Positron Version:

Positron Version: 2024.03.0 (Universal) build 893
Code - OSS Version: 1.87.0
Commit: 864257d
Date: 2024-03-05T03:24:32.501Z
Electron: 27.3.2
ElectronBuildId: undefined
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Darwin arm64 23.3.0

Steps to reproduce the issue:

1. try different keybindings, Explorer Cmd + Shift + E, Run and debug Cmd + Shift + D

Kapture.2024-03-11.at.11.44.49.mp4

What did you expect to happen?

Some of the listed keybindings on hover doesn't work because they are superseded by R package development commands.

I don't know if it would possible to hide the incorrect shortcuts.

As far as I can tell, I don't have any custom keybindings, so this is vanilla

Were there any error messages in the output or Developer Tools console?

Nope

[juliasilge]

This is a duplicate of #2150 but maybe the right call is to move these keyboard shortcuts to the RStudio Keymap extension. This would not get rid of the actual problem (on hover, you see a keybinding that does not actually apply in your current situation) but it would mean that a) folks opt IN to using it and b) fewer users total would be in this situation.

[lionel-]

Notes from the duplicate issue that I filed at #2673:

We currently define a bunch of "cmd+shift+" bindings in the R extension. These are high value bindings that are more likely to cause conflicts with existing Code/Positron bindings, for instance we bind "cmd+shift+e" to check a package inside R projects which conflicts with the regular keybinding to show the file explorer.

Now that we have an RStudio keymap extenstion (#2067) I think this frees us to come up with default keybindings that are less likely to conflict with the larger ecosystem. We could:

• Move keybindings such as Cmd+Shift+E from the positron-r extension to the RStudio-keymap extension.

• Create new ones in positron-r that don't conflict with VS Code. These will be useful for those of us that primarily use VS Code shortcuts but still want a way to invoke R commands with the keyboard.

  Since there are many commands and thus many keybindings, we might want to use the same approach as the Cmd+K prefix key. For instance we could use Shift+Cmd+K as a prefix key, then we'd have Shift+Cmd+K E to check a package, Shift+Cmd+K B to build one, etc.

  (I see that Shift+Cmd+K is used by Quarto for preview though, so we might need a different prefix.)

I've filed this issue in the RC milestone but I would personally bump it to Public Beta.

[lionel-]

@hadley mentions Cmd+R would be an obvious prefix. It doesn't seem to be used for anything important:

[juliasilge]

During our private beta Q&A session, there was some discussion of folks who want to use the R package development shortcuts but not opt in to the RStudio keymap FWIW.

[hadley]

One reason Cmd + R isn't used for anything important is because it probably can't be remapped in the browser, since it's used for refresh.

[lionel-]

I'm experimenting with this keymap. The Cmd+' prefix is available and easy to type on qwerty. Feels good so far!

Is there any reasons we'd not be able to use this prefix?

Edit: We might want to namespace dev keybindings further in Cmd+' Cmd+D. This way we can add a bunch of other usethis based commands within that namespace while keeping the main prefix available for other positron gestures. For instance I'd love:

• Cmd+' Cmd+C toggle console
• Cmd+' Cmd+V toggle variables
• Cmd+' Cmd+P toggle plots
• Cmd+' Cmd+H show help for object at point
• Cmd+' Cmd+. console assists, e.g. quick-pick menu of customisable commands like print(), summary() or str() for the object under cursor, see Provide a way to preview and/or open a Python or R data frame from the editor #2974 (comment)

[juliasilge]

We have collected a number of issues that are related to this problem where the UI always shows a built-in keybinding, even when that keybinding does not apply to that action. The user might end up looking at the UI and trying that keybinding, but it does something completely different. Let's use #2150 to track this problem.