Add code actions on save #6486

jpttrssn · 2023-03-30T12:27:46Z

Addresses issue #1565

Add a per language config option for code-actions-on-save that takes a list of LSP actions to run in order during save
Verify configured code actions against available source code actions for the entire document being saved
Apply actions on write and write_all before auto formatting
Refactor to reduce duplicate code
Update languages configuration documentation

cd-a · 2023-03-31T03:35:15Z

Nice!

Does this work with #2507?

As far as I can see, that was the only feature that was still not working there

jpttrssn · 2023-03-31T12:56:59Z

This would need some work to be compatible. I can work on adding my changes on top of that PR.

cd-a · 2023-03-31T15:44:47Z

That would be amazing. That PR should be merged soon.

pascalkuthe

Thanks for taking this on! I left some minor comments. I think we will likely land #2507 before this one since that has been waiting around for a longtime and while sometimes merging bugfixes before that PR makes sense ideally I think we should holdoff adding new LSP related features until after that lands.

pascalkuthe · 2023-04-14T01:16:49Z

helix-view/src/document.rs

+    #[inline]
+    pub fn full_range(&self) -> Range {
+        Range::new(0, self.text.len_chars())
+    }
+


I dont think this needs a dedicated helper method. We have far more common operations that don't have helper methods. Adding too many helper methods clutters the (already very large) document impls even more

pascalkuthe · 2023-04-14T01:29:17Z

helix-view/src/document.rs

+            if code_actions.len() < code_actions_on_save.len() {
+                code_actions_on_save.iter().for_each(|configured_action| {
+                    if !code_actions.iter().any(|action| match action {
+                        helix_lsp::lsp::CodeActionOrCommand::CodeAction(x) => match &x.kind {
+                            Some(kind) => kind.as_str() == configured_action,
+                            None => false,
+                        },
+                        _ => false,
+                    }) {
+                        log::error!(
+                            "Configured code action on save is invalid {:?}",
+                            configured_action
+                        );
+                    }
+                })
+            }


I don't think these code actions are necessarily returned on every import so this would potentially generate a lot of errors. This should atlest be an infolog but this alsoO(NM)` so I am not sure we really need this anyway?

Also, I think a for loop is basically always more idiomatic than for_each

I agree this isn't great. I struggled to find a good solution for this. Ideally this would be done at the same time as the filtering with the code_actions.retain() above. Perhaps a for loop there instead? I can play around with it some more and see if I can come up with something. Otherwise I'm fine with leaving this out. It's a nice to have, but like you said perhaps not needed.

pascalkuthe · 2023-04-14T01:33:11Z

helix-view/src/document.rs

+                matches!(
+                    action,
+                    helix_lsp::lsp::CodeActionOrCommand::CodeAction(x) if x.disabled.is_none() &&
+                        code_actions_on_save.iter().any(|a| match &x.kind {


probably a good idea to make this a HashSet so we avoid being O(MN) here even if M and N is usually small frserializing to a HashSet just takes replacing Vec with HashSet

pascalkuthe · 2023-04-14T01:37:11Z

helix-term/src/commands/lsp.rs

-            trigger_kind: Some(CodeActionTriggerKind::INVOKED),
-        },
-    ) {
+    let future = match doc.code_actions(selection_range) {


I don't think we should move this to a function on the document. This doesn't need to be moved into helix-view for this PR to work. Just moving this to a separate function inside commands/lsp.rs works just as well. We generally try to keep the LSP-related stuff separate from the core document primitives. Same for the other function you added to the document (which should also just be a standalone function in this file)

Alright, cool. That makes sense.

cd-a · 2023-05-19T10:26:22Z

#2507 has been merged now, which should enable this PR

jpttrssn · 2023-05-19T19:14:16Z

Great! I'll update this PR as soon as I've got my changes working with master.

ravsii · 2023-05-19T21:14:25Z

@jpttrssn this only adds pre-defined LSP actions on save, but no support for third-party commands, like vscode's run on save?

just asking

pascalkuthe · 2023-05-19T23:05:33Z

No that's out of scope for this PR. This PR should only implement support for the relevant part of the LSP spec

cd-a · 2023-06-12T13:04:37Z

Any luck getting it rebased on latest master? Would love to test it again

jpttrssn · 2023-06-14T07:02:20Z

I've made some progress, but haven't had much time to work on it. I'll try to make some time, though. I also want to get this done.

jpttrssn · 2023-06-17T15:22:02Z

Finally got this rebased with master. Manually tested with the following language config:

[[language]]
name = "go"
code-actions-on-save = ["source.organizeImports", "source.invalid"]

cd-a · 2023-06-17T16:07:30Z

Great news, thanks @jpttrssn !

Any idea how to test this with TS/TSX?

I tried this under the language config but it doesn't have any effect

code-actions-on-save = ["source.fixAll.eslint"]

archseer · 2023-06-19T02:09:40Z

helix-core/src/syntax.rs

@@ -105,6 +105,8 @@ pub struct LanguageConfiguration {
    pub comment_token: Option<String>,
    pub text_width: Option<usize>,
    pub soft_wrap: Option<SoftWrap>,
+    #[serde(default)]
+    pub code_actions_on_save: HashSet<String>, // List of LSP code actions to be run in order upon saving


A HashSet is ordered based on the item's hash value though. Let's just use a Vec here since I can also imagine usecases where you would want to execute action A, B then A again

Yeah, this should be a Vec to keep the ordering.

archseer · 2023-06-19T02:14:44Z

helix-term/src/commands/lsp.rs

+    Some(
+        code_actions_for_range(doc, full_range)
+            .into_iter()
+            .map(|(request, ls_id)| {
+                let code_actions_on_save = code_actions_on_save_cfg.clone();


This assumes that we can trigger multiple code actions in parallel, which works in some cases, but one action might impact another action (e.g. if A removes a function, and B formats the file). Maybe to simplify we should limit to a single code action on save (since that's the majority usecase anyway)

If I'm understanding the LSP spec as long as the requests are in the correct order, the lsp should determine how best to execute those requests.

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#messageOrdering

Right, but if you send actions A and B in parallel, the server is computing the edits based on that initial state. Server only considers the change applied when we send back a didChange event. Helix does use OT internally to transform edits (so initial state -> A -> B can be applied) but it's not necessarily going to produce the same result as if we requested A, applied, then requested B and applied B.

But over multiple language servers we can't guarantee the order. That's what you were getting at, I assume. Simplifying to a single code action would definitely make this problem go away, though then we are not feature parity with VSCode, if that is important.

Right, but if you send actions A and B in parallel, the server is computing the edits based on that initial state. Server only considers the change applied when we send back a didChange event. Helix does use OT internally to transform edits (so initial state -> A -> B can be applied) but it's not necessarily going to produce the same result as if we requested A, applied, then requested B and applied B.

Ok, I see. Thanks! Let me know which direction we want to take and I can make the changes.

jpttrssn · 2023-06-20T19:36:26Z

Any idea how to test this with TS/TSX?

I tried this under the language config but it doesn't have any effect
code-actions-on-save = ["source.fixAll.eslint"]

source.fixAll.eslint appears to be specific to the VSCode Eslint extention. See: https://github.com/microsoft/vscode-eslint#settings-options

Addtionally, this PR only allows executing code actions that are returned from the LSP selecting over the range of the entire document. It would be the same as if you did %-space-a in the editor. I based this off of the PR to add code actions on save to VSCode: microsoft/vscode#48086

There is definitely room for adding more functionality, but perhaps out of scope for this PR?

rcorre · 2023-06-30T13:28:28Z

This is great, I'm using it with source.organizeImports in Go and it seems to work well.

Out of curiosity, how do you know what the name of an "action" is, or what actions a particular LSP supports? I just copied "source.organizeImports" from the docs in the PR, but I have no idea how I'd figure out what else I could put in there, or if it would be the same for other language servers.

jpttrssn · 2023-07-01T18:53:25Z

Out of curiosity, how do you know what the name of an "action" is, or what actions a particular LSP supports? I just copied "source.organizeImports" from the docs in the PR, but I have no idea how I'd figure out what else I could put in there, or if it would be the same for other language servers.

There are only two source actions defined in the LSP spec (source.organizeImports and source.fixAll). However, the spec leaves the option for a language server or extension to provide additional source actions. I have myself yet to find a LSP I can use to test this PR with a source.fixAll.

As a side note, I'm in the process of re-working this PR to apply the configured code actions in order (applied individually) and enabling the source.fixAll option.

jpttrssn · 2024-04-30T17:41:50Z

This probably needs a revisit at this point. From the sound of it this PR might benefit from the new "event system" that came out in the latest release (24.03). I'll see if I can find some time to see what's possible there.

ds-281 · 2024-05-02T08:21:31Z

That would be much appreciated, thank you.

It's nice that the goimports trick works, but relying on it adds an extra dependency to the system that feels unnecessary and, to my understanding, relies on the fact that only one action is needed (as opposed to this PR, which takes a list of LSP actions to run upon save).

* Add code-actions-on-save config * Match VS Code config to allow future flexibility * Refactor lsp commands to allow for code reuse * Attempt code actions for all language servers for the document * Add lsp specific integration tests * Update documentation in book * Canonicalize path argument when retrieving documents by path * Resolves issue when running lsp integration tests in windows

Philipp-M · 2024-09-02T12:49:49Z

(Just a suggestion: I'd use additional commits instead of rebasing/ammending, so that it's easier to track what has changed since the last push)

jpttrssn · 2024-09-03T08:08:51Z

(Just a suggestion: I'd use additional commits instead of rebasing/ammending, so that it's easier to track what has changed since the last push)

OK! Didn't think anyone was paying attention. I'm currently working through issues getting my tests to go through on windows and didn't think anyone would be interested in seeing those commits. Switched to doing this on my fork instead.

ds-281 · 2024-09-03T08:17:51Z

Indeed, I'm also following this issue, and since I'm not overly familiar with Rust (and this project's structure) I would have had an easier time to compare the changes incrementally.

Of course, once the work is done and ready for review, squash-rebasing everything in a perfect set of commits without mistakes makes sense if that's what you prefer.

jpttrssn · 2024-09-03T19:40:05Z

@archseer @pascalkuthe

Some notable changes in this latest revision are the addition of integration tests, ensuring that write_all_quit works and running the code actions directly in the typed::write_* functions (instead of a job).

Note that there is a race condition between the textDocument/didChange notification and running the next code action and/or auto-format which I've "solved" with a sleep. Obviously not an ideal solution. This also causes the lsp integration tests on the Windows runner to fail unless the tests are not run in parallel. It looks like there is a TODO to make applying work space edits transactional, which sounds like it might help here. Other ideas and/or guidance welcome.

Also, I experimented with using a job to handle the code actions, but this causes a panic with write_quit/write_all_quit (i.e., block_try_flush_writes) because of the need to use helix_lsp::block_on in the callback in order to both call async lsp functions and have access to the editor for applying workspace edits. If running this in a job is preferred, one workaround could be to run multiple jobs with a single code action (per language server) in a sequence (which I have experimented some with), but would be more complex and then there's still the race condition mentioned above.

Long story short this felt like the most straight forward approach and a good starting point with room for future improvements. Let me know what you think!

the-mikedavis · 2024-09-03T20:24:48Z

I'm very wary of adding integration tests against a language server. As you have in the code already we need to install the language server in CI and require that you install it if you want to run the tests manually, the tests need to sleep pretty pervasively to wait for the language server to respond, and we need to work around language-server-specific oddities like the LF line-ending setting here. If we want to test different features we need to test against many servers: if we want to test pull diagnostics (#11315) for example we need to depend on a version of language servers that uses that feature. Plus I don't think that the code paths involved with this feature will change often enough that the tests would catch a breakage that woludn't be caught in review. On balance I don't think LSP integration tests are worth their added weight and I would prefer we test LSP features manually.

What do you think @archseer & @pascalkuthe?

jpttrssn · 2024-09-08T08:43:50Z

In c314acb I resolved the need to sleep to fix the race condition by allowing the textDocument/didChange notification to be sent synchronously (only during on save). Tried to have this affect as little other code as I could.

jpttrssn force-pushed the code-actions-on-save branch from f4c9f40 to 7d642ee Compare March 30, 2023 12:56

pascalkuthe reviewed Apr 14, 2023

View reviewed changes

pascalkuthe added A-language-server Area: Language server client E-medium Call for participation: Experience needed to fix: Medium / intermediate S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 14, 2023

pascalkuthe mentioned this pull request Apr 14, 2023

lsp doesn't handle code action refactor.extract.* #6702

Closed

jpttrssn force-pushed the code-actions-on-save branch from 7d642ee to 0365774 Compare April 18, 2023 18:12

pascalkuthe added S-waiting-on-review Status: Awaiting review from a maintainer. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 18, 2023

jpttrssn force-pushed the code-actions-on-save branch 2 times, most recently from 1f6a002 to 3b51a53 Compare June 17, 2023 15:08

archseer reviewed Jun 19, 2023

View reviewed changes

cd-a mentioned this pull request Jun 21, 2023

Default language server settings for TypeScript/Eslint/Prettier #7079

Closed

jpttrssn force-pushed the code-actions-on-save branch 2 times, most recently from ebb8dfc to e40d16e Compare September 16, 2023 19:54

jpttrssn force-pushed the code-actions-on-save branch from 0d75992 to 076f63b Compare August 22, 2024 18:46

jpttrssn marked this pull request as draft August 23, 2024 14:10

jpttrssn force-pushed the code-actions-on-save branch 8 times, most recently from 46b50b7 to 22e849b Compare September 2, 2024 08:44

jpttrssn force-pushed the code-actions-on-save branch from 22e849b to af5a16f Compare September 2, 2024 12:22

Use custom idle timeout in tests

b3bf1c6

jpttrssn added 3 commits September 3, 2024 19:30

Set default line ending to LF in tests

6dc9644

Reduce sleep to 10ms

67eaf5c

Code cleanup

ae5844a

jpttrssn marked this pull request as ready for review September 3, 2024 19:40

jpttrssn requested review from archseer and pascalkuthe September 3, 2024 19:40

jpttrssn added 2 commits September 8, 2024 10:36

Allow textDocument/didChange notification to be synchronous

c314acb

Use FuturesOrdered; Fix from rebase conflict

edca920

Omar-Elrefaei mentioned this pull request Dec 5, 2024

Barebones LSP for integration testing #9430

Closed

Add code actions on save #6486

Are you sure you want to change the base?

Add code actions on save #6486

Conversation

jpttrssn commented Mar 30, 2023 • edited Loading

cd-a commented Mar 31, 2023

jpttrssn commented Mar 31, 2023

cd-a commented Mar 31, 2023

pascalkuthe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cd-a commented May 19, 2023

jpttrssn commented May 19, 2023

ravsii commented May 19, 2023

pascalkuthe commented May 19, 2023

cd-a commented Jun 12, 2023

jpttrssn commented Jun 14, 2023

jpttrssn commented Jun 17, 2023

cd-a commented Jun 17, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

archseer Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jpttrssn commented Jun 20, 2023

rcorre commented Jun 30, 2023

jpttrssn commented Jul 1, 2023

jpttrssn commented Apr 30, 2024

ds-281 commented May 2, 2024

Philipp-M commented Sep 2, 2024

jpttrssn commented Sep 3, 2024

ds-281 commented Sep 3, 2024

jpttrssn commented Sep 3, 2024

the-mikedavis commented Sep 3, 2024

jpttrssn commented Sep 8, 2024

jpttrssn commented Mar 30, 2023 •

edited

Loading

archseer Jun 19, 2023 •

edited

Loading