Switch R package development support to commands

[juliasilge]

Addresses #747 and also #735

This isn't quite right yet, because the terminal (pseudoterminal?) takes focus while the task is being run.

[juliasilge]

Looks like what we want is "reveal": "never".

[juliasilge]

I know I was the one making the argument that these package management needs should be tasks, but the API is much more complicated compared to commands and I now think the best option in the short term is to offer these as commands.

In the long run, we can reevaluate whether tasks are better, because they would allow us to take advantage of the problem matchers infrastructure.

[juliasilge]

Should I add some quick-and-dirty keybindings for these commands here, for the private alpha? Or wait for #669? It would look like:

    "keybindings" : [
      {
        "command": "r.packageLoad",
        "key": "ctrl+shift+l",
        "mac": "cmd+shift+l",
        "when": "isRPackage"
      },
      {
        "command": "r.packageBuild",
        "key": "ctrl+shift+b",
        "mac": "cmd+shift+b",
        "when": "isRPackage"
      },
      {
        "command": "r.packageTest",
        "key": "ctrl+shift+t",
        "mac": "cmd+shift+t",
        "when": "isRPackage"
      },
      {
        "command": "r.packageCheck",
        "key": "ctrl+shift+e",
        "mac": "cmd+shift+e",
        "when": "isRPackage"
      }
    ]

Also, I can quickly add devtools::document() too

[jmcphers]

I think these keybindings are already taken in VS Code so we shouldn't override them with RStudio keybindings unless the user has intentionally enabled RStudio keybindings.

Maybe the default keybindings for these could use some kind of leader sequence? (e.g. VS Code uses Cmd+K a lot as a leader sequence)

[juliasilge]

Totally happy to wait on the keybindings but with the when clause, it only overrides them when we are in an R package (and if the user has their own custom keybindings, those take preference). I am totally fine to wait on this until we have a more comprehensive keybindings solution, but I can't think what else someone would want to use, say, a default build task key binding for in an R package, other than this.

[jmcphers]

Agree, we could probably take over the Run Build Task keybinding. The others, though, already have meaning. Cmd+Shift+E focuses the Explorer tab, Cmd+Shift+T focuses the previous editor, etc.

[juliasilge]

OK, let's wait on the keybindings then. 👍

[juliasilge]

Addresses #28

#122 is about about stopgap keybindings for an initial release, so if we don't want to do that in favor of a better longer term option, maybe we should close?

[jmcphers]

Yeah, I think we should close #122.

[jjallaire]

I actually think that we should bind these keyboard shortcuts, because they are scoped to only exist when the user is working on an R package (a strong signal that they'll use and benefit from these keybindings). A similar example was that I took Cmd+Shift+K for Render in Quarto (even though it is "delete line" in VS Code). If these are bound to mainline, commonly used editing commands that's one thing, but if they are more obscure I think we should take them.

[juliasilge]

Now definitely addresses #122 with our initial solution (to be replaced in the longer term by #669)