Expose & Unexpose (existing code lens) as code actions

[jonathanmoregard]

When I want to expose a Thing (= type, class, function, pattern etc) to other modules, I have to:

1. Scroll to the top of the file
2. Type the name of the Thing I want to expose in the "module export list"
3. Scroll back down to continue coding.

I propose 2 new code actions to make this easier:

1. Expose (for Things not in the module declaration): add that Thing to the "module export list"
2. Unexpose (for Things currently in the module declaration): remove that Thing from the "module export list"

[ndmitchell]

Personally I think this is just a question of Haskell having got it very wrong, and something like Rust having got it right. Instead of making the exposed-ness of a value dependent on a list at the top of the file, add a pub/export keyword before an identifier. I think that would be a worthwhile GHC proposal, but requires a fair amount of thought.

As for adding code actions, that would result in at least 1 additional code action per top-level declaration, which would be very busy using the VS Code UI, and thus a bit of a problem.

[jneira]

I think my comment in the other feature request could be applied here: till now we are not adding isolate code actions to minimize the amount of code logic in editors code.

There is a export x quick fix linked to the Defined but not used: x warning so somewhat half of the functionality is covered. Only for the elements that triggers that warning, of course.

[jonathanmoregard]

As for adding code actions, that would result in at least 1 additional code action per top-level declaration, which would be very busy using the VS Code UI, and thus a bit of a problem.

Busy in what way? I'm not suggesting adding a per line code lens, just a "ctrl+." action that doesn't add a bunch of lines. Did I understand your concern correctly?

[ndmitchell]

My understanding was code lens always showed up in VS Code. In other editors it might not. If there is some LSP functionality that could put this behind a key binding that would be great. CC @alanz as our LSP expert.

[alanz]

As I understand it "ctrl+." in vscode brings up the code actions, which are then presented in a sorted way.

The hierarchical sorting is based on CodeActionKind, defined in the spec as

/**
 * The kind of a code action.
 *
 * Kinds are a hierarchical list of identifiers separated by `.`,
 * e.g. `"refactor.extract.function"`.
 *
 * The set of kinds is open and the client needs to announce the kinds it
 * supports to the server during initialization.
 */
export type CodeActionKind = string;

So we should perhaps start applying a disciplined process to putting a code action kind hierarchy into place, and push the other LSP clients to use them properly in the UI

[carlwr]

Cross-posting my comment in #496 (comment) since it is relevant for both issues:

---

This would be a great thing to have.

I have chosen to disable code lenses since I find it clutters the code (granularity of settings for enabling code lenses in various contexts is limited, so electing to turn them off completely for the moment), however, this currently means I can't use the eval plugin.

---