-
Notifications
You must be signed in to change notification settings - Fork 92
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
(Start to) handle cli hyperlinks in the terminal used for pkg dev tasks #5231
Conversation
@@ -3,7 +3,7 @@ | |||
"displayName": "%displayName%", | |||
"description": "%description%", | |||
"version": "0.0.2", | |||
"publisher": "vscode", | |||
"publisher": "positron", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this should be the case for all extensions we (Positron) have introduced. Harder to say what should happen to VS Code built-in extensions that we modify, but worth thinking about.
The relevance to this PR is that the publisher
affects the form of URI that the associated extention (positron-r, in this case) is allowed to handle. The general form is:
{product-name}://{publisher}.{extension-name}
which means that positron-r can handle URIs that begin like so:
positron://positron.positron-r
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From #5268, we're going to use "positron" as publisher here.
Addresses #1957 Requires posit-dev/ark#625 What's the payoff? * Sometimes you want to get info about a package version without necessarily challenging the user to install/upgrade. (I need this to finish #5231, for example). * If you do need to invite the user to install or upgrade a package, this extra info allows us to build a better message. ### QA Notes To experience that `checkInstalled()` still works and to see the user-facing message in the absence of a minimum version requirement, here's one idea: * Remove the styler package: `remove.packages("styler")` * Trigger the *Format Document* command You should see this: <img width="404" alt="Screenshot 2024-11-13 at 3 46 39 PM" src="https://github.com/user-attachments/assets/2231ec70-d335-4f99-b5f9-598cd1c19301"> To experience that `checkInstalled()` still works and to see the user-facing message in the presence of a minimum version requirement, here's one idea: * Install renv at a version below positron-r's minimum version, which is currently 1.0.9. I would do this with `pak::pak("[email protected]")`. * Walk through *File > New Project > R Project* and click the box to use renv: <img width="701" alt="Screenshot 2024-11-13 at 3 35 45 PM" src="https://github.com/user-attachments/assets/430908cb-9fce-43fe-8d39-a6fec56f9a70"> As the new project is being stood up, you should see this: <img width="401" alt="Screenshot 2024-11-13 at 3 37 12 PM" src="https://github.com/user-attachments/assets/ee3d82a1-5479-47e6-82bd-a693583d2f4a">
a64b778
to
d78dff0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is working well for me! 🎉
My main question is about the file hyperlinks. I understand that this PR is not meant to address those but it leaves us in a state where both kinds of hyperlinks look like you should click them but clicking one kind results in something nice and clicking another kind results in something QUITE UNPLEASANT. Is it possible not to make file hyperlinks clickable, since we're not yet handling them? If not, can we put this new feature behind a feature flag until #5409 is resolved? Right now we have landed a combo of "looks just like what I should click" plus "both surprising and awful result".
Unfortunately it's not (yet?) possible to have the run/help/vignette hyperlinks but not have file hyperlinks. At least, AFAIK, it's not possible and I'm pretty up to speed on this part of cli right now. I feel like we can safely merge and I will tackle #5409 in the near term. This is behind an implicit feature flag of sorts, in that we only activate the hyperlinks in the presence of truly bleeding edge cli (version 3.6.3.9001). It's not just any dev version, but a dev version I bumped to specifically for this (r-lib/cli@9d6e9db). I think the few people who might install this version of cli can probably cope for the couple weeks until file hyperlinks fully catch up. Plus, as an experiment, I just changed the macOS file affiliation for |
// cli 3.6.3.9001 gained support for configuring the URL format for hyperlinks. | ||
const cliPkg = await session.packageVersion('cli', '3.6.3.9001'); | ||
const cliSupportsHyperlinks = cliPkg?.compatible ?? false; | ||
|
||
if (!cliSupportsHyperlinks) { | ||
// eslint-disable-next-line @typescript-eslint/naming-convention | ||
return { R_CLI_HYPERLINKS: 'FALSE' }; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's where we exit early, without activating hyperlinks in the integrated terminal, in the absence of bleeding edge cli.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is behind an implicit feature flag of sorts, in that we only activate the hyperlinks in the presence of truly bleeding edge cli (version 3.6.3.9001).
I am not a fan of this getting merged into main as is, but this is a fair point. Can you confirm with Gabor and take on making sure that we do not get a surprise cli release before the file hyperlinks are fixed up?
Alternatively, you could throw a quick IsDevelopmentContext
around this to gate it from being exposed to users as is?
Yes @gaborcsardi has confirmed there will be no surprise cli release. I don't love the idea of the "dev build only" gate, because I am hoping to use this in my package dev work, where I generally use a an Positron release build (albeit a daily). If if we think it needs to be gated, I could add a setting for it. |
Feature flag is in. |
Addresses #5218
This PR makes suggested code hints like
testthat::snapshot_accept()
ortestthat::snapshot_review()
clickable and runnable from the integrated terminal where positron-r sends package development tasks, such asdevtools::test()
. "Runnable" in the sense that the code is run in the user's R console. This gets routed into the same handlers as clickable code entered directly in the console, so the existing safety guards are in place.(Note that this PR does not change behaviour for file hyperlinks, which I've crossed out in the screenshot above. Those hyperlinks currently get delegated to the operating system, so for many R users, a
.R
file will open in RStudio. Changing that is a separate problem #5409.)QA Notes
To see the new behaviour, you need a development version of the cli R package. I would install that via
pak::pak("r-lib/cli")
. (Context: r-lib/cli#739.)Then you need to run tests or
R CMD check
on a package with a failing snapshot test, in order to get a clickable invitation to accept a new snapshot or to review the proposed snapshot in a Shiny app. I have made a toy package that could be obtained viausethis::create_from_github("jennybc/clilinks")
. It has a couple of snapshot tests that will always fail 😄 because they attempt to snapshot a random number.pak::pak("r-lib/cli")
usethis::create_from_github("jennybc/clilinks")
If you click
testthat::snapshot_review()
, you should see the code execute in the R console and this Shiny app appears. Click on "Accept" (the fact that "Skip" seems broken is r-lib/testthat#2025 and unrelated to this PR).