search

posit-dev / positron

Positron, a next-generation data science IDE
Other
2.57k stars 79 forks source link

UI shows the wrong keyboard shortcut with `"when": "isRPackage"` or when RStudio Keymap is enabled #2150

Open juliasilge opened 8 months ago

juliasilge commented 8 months ago

We have at least one keyboard short specific to R packages that overrides a VS Code default:

https://github.com/posit-dev/positron/blob/39ff5aa20a4d15cf64f3e58a96e592f7609d9a93/extensions/positron-r/package.json#L329-L334

During usability testing with @andrie we noticed that the UI does not reflect that override:

wrong-shortcut

I don't know how hard-coded these are and whether we might consider removing them or otherwise dealing with this. It does seem bad that you see that shortcut suggested when that is not what it will do.

jennybc commented 8 months ago

I can't tell from this screenshot, where I just see Shiny-related files. Just to confirm: the current workspace is an R package? If you actually press Ctrl + Shift + E, do you get devtools::check()?

andrie commented 8 months ago

Yes, Shift + Ctrl + E triggers devtools::check() - which is what I would expect.

But that same keyboard shortcut is the default VS-code key for switching to the files pane.

jennybc commented 8 months ago

This is a bit of "passing the buck" but I wonder if VS Code has hard-wired that UI (the hint about the keyboard shortcut) when really it shouldn't?

juliasilge commented 1 month ago

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. So far this has come up in situations like "when": "isRPackage" or when the RStudio Keymap is enabled. Let's use this issue to track this problem and close the others.

Related:

If we tackle and totally resolve https://github.com/posit-dev/positron/issues/3993, that will not solve this issue, which is kind of the opposite problem.

This happens in VS Code itself, but it feels worse in Positron because we bundle more extensions and have more @builtin extensions that are needed to use Positron functionality.