Consider a 💡 Code Action that opens `DESCRIPTION` or `NAMESPACE` of package at cursor

[DavisVaughan]

From #1172 (comment)

Say you write dplyr::across() or library(dplyr)

We probably want Cmd+Click anywhere on dplyr::across() to goto-definition, that seems like it would be the most expected behavior from most users.

But some people may want an easy way to jump to package metadata about dplyr.

We could have a Code Action when the user's cursor is on dplyr of dplyr::across() or library(dplyr) that pops up a 💡 and gives them a few options, like:

• Open DESCRIPTION
• Open NAMESPACE
• Open package documentation ("_PACKAGE")

[jennybc]

Another idea:

Navigate to that package's website or github home. Basically mine the URLs in its DESCRIPTION. Something along the lines of what usethis::browse_package() does.

[DavisVaughan]

That's fun too!

[lionel-]

Can code actions navigate to other files?

[DavisVaughan]

I believe code actions can do all kinds of arbitrary things!

We use them for simple workspace edits right now, but there is a Command field that is currently unused by us

interface [Command](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command) {
	/**
	 * Title of the command, like `save`.
	 */
	title: string;
	/**
	 * The identifier of the actual command handler.
	 */
	command: string;
	/**
	 * Arguments that the command handler should be
	 * invoked with.
	 */
	arguments?: [LSPAny](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#lspAny)[];
}

The command is an arbitrary command to run that the client is supposed to know about

For example, rust-analyzer registers its own commands as

    pub fn client_commands(&self) -> ClientCommandsConfig {
        let commands = self.commands().map(|it| it.commands).unwrap_or_default();

        let get = |name: &str| commands.iter().any(|it| it == name);

        ClientCommandsConfig {
            run_single: get("rust-analyzer.runSingle"),
            debug_single: get("rust-analyzer.debugSingle"),
            show_reference: get("rust-analyzer.showReferences"),
            goto_location: get("rust-analyzer.gotoLocation"),
            trigger_parameter_hints: get("rust-analyzer.triggerParameterHints"),
            rename: get("rust-analyzer.rename"),
        }
    }

and, for example, triggerParameterHints gets set as the command to run

    /// Triggers the parameter hint popup after the assist is applied
    pub fn trigger_parameter_hints(&mut self) {
        self.command = Some(Command::TriggerParameterHints);
    }

You can see the translation from this back to LSP command world in to_proto::code_action()

    pub(crate) fn trigger_parameter_hints() -> lsp_types::Command {
        lsp_types::Command {
            title: "triggerParameterHints".into(),
            command: "rust-analyzer.triggerParameterHints".into(),
            arguments: None,
        }
    }

They have registered rust-analyzer.triggerParameterHints as an extension command on the typescript side, and finally on the typescript side they have that wired up to just call vscode.commands.executeCommand("editor.action.triggerParameterHints")

export function triggerParameterHints(_: CtxInit): Cmd {
    return async () => {
        const parameterHintsEnabled = vscode.workspace
            .getConfiguration("editor")
            .get<boolean>("parameterHints.enabled");

        if (parameterHintsEnabled) {
            await vscode.commands.executeCommand("editor.action.triggerParameterHints");
        }
    };
}

So we could probably do something similar and make use of the arguments field to determine which file to open

(Commands like this seem super powerful in general!)

[DavisVaughan]

Oh and actually rust-analyzer.gotoLocation looks VERY similar to what we would want!

I believe it is what powers the Go to <so-and-so> part of the help popup here

To do that they enhance normal LSP Hover with arbitrary Command actions they can append to the bottom of the Hover output, which they catch in their raMiddleware on the typescript side (we should not need to do this for code actions, which support Commands already)

[lionel-]

oh that's neat! Offering this sort of navigation when hovering package names would be nice