Support textDocument/diagnostic specification (Pull diagnostics) #11315

SofusA · 2024-07-25T11:25:05Z

Closes #7757, if workspace diagnostics is not a requirement. I have not yet found a language server which supports this capability.

Handling of response was originally done by @woojiq in #7900. I was not able to include their git history since their branch has been deleted.

Tested with language servers:

eslint version 4.10.0
roslyn language sever for C# version 4.12.0
ruby-lsp

Diagnostics are pulled when a document is changed for each language server with pull diagnostics feature with an async hook after a debounce period.

Diagnostics are also pulled when a document is opened, when changed to buffer and when a language server is successfully initiated. This is done without debounce.

rust-toolchain.toml

helix-term/src/commands/lsp.rs

helix-term/src/ui/editor.rs

helix-term/src/handlers/diagnostics.rs

helix-view/src/handlers/lsp.rs

SofusA · 2024-08-12T19:37:09Z

Thanks again for the reviews!
I added your comments and did some refactoring. I closed the conversations, i am sorry if it is usually the reviewer who does this.

The request is currently only being send on document changes, which makes a terrible user experience 😄

Is there a way to send this request when a document is opened, or should a workspace diagnostic event be send when the language server (which supports this feature) is started?

Edit: By the way, i am using this branch daily for C# development, since it allows me to use the same language server as the C# vscode extension. So i am keeping the branch up to date with master branch. Let me know if the merge commits is making too much noise.

SofusA · 2024-08-13T19:31:59Z

I did some experiments with this on roslyn language server. It might be that this language server just behaves weird (which it does on other stuff), but sending workspace/diagnostic after the server is initiated always resulted in and empty diagnostic list. Also with some seconds delay.

I also noticed that responses can either be a full or an related unchanged document report. At the moment, since we only listening on changes, we only get the full reports. This means that when i eg. rename something, i will not see diagnostics on related documents until i make a change.

I am not sure if the specification suggest to pull diagnostics every time a document is viewed, or if we should pull diagnostics for all open documents on changes to a document.

Edit: Pulling diagnostics for all open documents seems to work fine actually.

SofusA · 2024-08-13T20:23:44Z

My plan is to send pull diagnostics request:

When current document is edited for all open documents, if possible where other documents has same active language server by id as edited document
When a new document is opened

SofusA · 2024-08-15T18:37:15Z

Edit: This is no outdated.
I now pull diagnostics when a document has changed for that document for each language server with pull diagnostics feature. This is done with a async hook with a debounce.

I also pull blocking when a document is opened or changed to buffer.

I chose this model because i thought pulling for all open documents on edit was too aggressive.

I have now added two events: *Pull diagnostics for documents* Trigger: When documents are opened Document ids are collected in a hashset After a short debounce all documents pull from all its language servers with pull diagnostics support.
Pull diagnostics for language servers
Trigger: When document are saved
Language server ids with pull diagnostics support from saved document are collected in a hashset.
After a longer debounce all language servers for all open document are pulled

Document ids are being passed around, and i do some cloning of ids.

~~Overall it appears to work well. At least better than the first implementation with idle timeout.~~

lizclipse · 2024-08-17T13:12:58Z

I've been trying this PR to see if it'll solve some issues using the ESLint LS from vscode-langservers-extracted, and I've run into a couple of bugs. Firstly, if you open a file directly using the CLI args, then the diagnostics won't show, and instead you have to close the buffer and re-open via the file picker. Secondly, and most noticable I think, if I then close this buffer and try to re-open it again then I get a crash:

thread 'main' panicked at helix-term/src/handlers/diagnostics.rs:144:19:
no entry found for key
stack backtrace:
   0: rust_begin_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
   1: core::panicking::panic_fmt
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_display
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:168:5
   3: core::panicking::panic_str
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:152:5
   4: core::option::expect_failed
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/option.rs:1988:5
   5: helix_term::handlers::diagnostics::pull_diagnostics_for_documents
   6: helix_term::job::Jobs::handle_callback
   7: helix_term::application::Application::run::{{closure}}
   8: tokio::runtime::park::CachedParkThread::block_on
   9: tokio::runtime::runtime::Runtime::block_on
  10: hx::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Of note, you do have to be using vscode-langservers-extracted@>=4.9.0 (I'm testing on 4.10.0), as that's when they changed something to stop the LS working originally, and is why I'm trying this.

SofusA · 2024-08-17T16:54:06Z

Thanks for testing!

Firstly, if you open a file directly using the CLI args, then the diagnostics won't show, and instead you have to close the buffer and re-open via the file picker.

I see the same behaviour with roslyn language server. I think this is because we are requesting diagnostics before the language server is ready. I was hoping that this would be the language servers responsibility. I am not sure what to do about this.
Diagnostics will be requested if you make a change to the document

Secondly, and most noticable I think, if I then close this buffer and try to re-open it again then I get a crash

I fixed this by skipping the diagnostics request if the document id is not in the editor.
I am not sure if this is the best solution.

Edit:

Of note, you do have to be using vscode-langservers-extracted@>=4.9.0 (I'm testing on 4.10.0), as that's when they changed something to stop the LS working originally, and is why I'm trying this.

I am actually (without knowing) been using vscode-eslint-language-server version 4.10.0 on this branch. It is working for me with pull diagnostics. @lizclipse Can you check if it work with my latest changes?

lizclipse · 2024-08-18T11:41:36Z

It looks like the crash is fixed now, thank you. I'd be curious on why the diagnostic request is trying to happen on a missing document ID (is there a memory leak somewhere?), but a little defensive programming didn't hurt anyone.

I've been testing this PR against v4.10.0 and so far it's been working (unlike the master branch, since eslint needs this now I think), although I am still getting the issue where it doesn't pick up the first open file. With my testing just now, it seems that it also doesn't pick up if you open helix blank and then open a file via the picker, you then have to re-open the file (or make an edit) before it starts showing anything. IMO I think functionally it's fine for this PR, but it may be worth opening an issue afterwards as a follow-up to at least document that this is known dodgey behaviour.

SofusA · 2024-08-18T18:11:16Z

I looked into it, and i am not sending the pull diagnostics request, because of a race between the event, and the launching the language server (and registering capabilities). The event wins 😄
In sequent events (open or edit) the language server will be initiated and capabilities are registered.

~~I have not found a good solution for this, which i find very annoying.~~
I have found a somewhat hacky solution, where i dispatch the DocumentDidOpen again after a language sever is initialized.

It looks like the crash is fixed now, thank you. I'd be curious on why the diagnostic request is trying to happen on a missing document ID (is there a memory leak somewhere?), but a little defensive programming didn't hurt anyone.

I am not completely sure why. I think part of it was because i was doing this asynchronous, where i collected all document_ids in a hashset, and then send all notifications after a debounce. I changed this to a synchronous hook instead.

the-mikedavis · 2025-02-04T15:49:22Z

I ported out the change to move the diagnostic handling from Application to Editor to master in 62625ed and rebased this.

I dropped a change though in https://github.com/SofusA/helix-pull-diagnostics/blob/3304a54ed45b42e5b3819fb8dd165386e854b3a7/helix-view/src/editor.rs#L2236-L2242: that was discarding diagnostics that came in without an open document. For some language servers that's ok since they only ever emit diagnostics for the opened documents but others like rust-analyzer can send documents for the whole workspace. For example if you change a function's name in one file, rust-analyzer should send diagnostics for all other files in the workspace that need to update the name.

SofusA · 2025-02-04T18:44:34Z

I ported out the change to move the diagnostic handling from Application to Editor to master in 62625ed and rebased this.

I dropped a change though in https://github.com/SofusA/helix-pull-diagnostics/blob/3304a54ed45b42e5b3819fb8dd165386e854b3a7/helix-view/src/editor.rs#L2236-L2242: that was discarding diagnostics that came in without an open document. For some language servers that's ok since they only ever emit diagnostics for the opened documents but others like rust-analyzer can send documents for the whole workspace. For example if you change a function's name in one file, rust-analyzer should send diagnostics for all other files in the workspace that need to update the name.

Awesome. Thanks!

Is there anything I could do to help complete this pull request? I am a little lost in the process.

the-mikedavis · 2025-02-04T19:04:31Z

For now no - I need to go throgh the spec and sit with the changes for a while and then I'll leave some review. I'd also like @pascalkuthe's review on the hook/event stuff but he's quite busy with work at the moment so in the meantime I'd like to minimize the changes with master so it's easy to rebase.

SofusA · 2025-02-10T15:06:06Z

For now no - I need to go throgh the spec and sit with the changes for a while and then I'll leave some review. I'd also like @pascalkuthe's review on the hook/event stuff but he's quite busy with work at the moment so in the meantime I'd like to minimize the changes with master so it's easy to rebase.

Great 👍

I think I have found an issue.

Diagnostics comes in one by one in an annoying way when language server responds slower than denounce value. See attached video. I can only reproduce in bigger dotnet codebase with StyleCop and Sonar diagnostics providers with the C# language server.

It don't think it is possible to cancel a pull diagnostic request, so maybe this just indicates that the debounce should be higher. Maybe 250 ms.

Screencast.From.2025-02-10.15-27-27.webm

Do you want me to keep rebaseing and tuning the debounce value on this branch?

the-mikedavis · 2025-02-10T21:10:35Z

Yeah feel free to push/rebase/force-push this branch as you see fit - I only force-pushed to resolve the conflicts and keep it to one commit as you had been doing

SofusA · 2025-02-21T15:54:03Z

I noticed, that latest rust-analyzer does provide pull diagnostic capabilities. But only some diagnostics are included in pull diagnostic responses. This partial diagnostic is then replacing all the diagnostics from the publish diagnostics.

I am not sure what to do here, and it should be handled before merge.
Any ideas?
My current best solution would be to store pull and push diagnostics separately, and render a joined list of diagnostics.

SofusA · 2025-02-22T16:30:46Z

I managed to solve this by changing DiagnosticProvider to an enum. Coincidentally, there was already a todo for this. I use this enum instead of LanguageServerId when something is related to diagnostics from a server.

Now, a language server can provide both types of diagnostics. Both rust-analyzer and the C# language server work 🎉

SofusA · 2025-02-22T18:42:09Z

It don't think it is possible to cancel a pull diagnostic request, so maybe this just indicates that the debounce should be higher. Maybe 250 ms.

I solved this issue by pull diagnostics on the first change, and then increase the debounce to 500 ms.
This both fixes the issue and the first diagnostic is now rendered 120 ms faster.

The debounce could easily be lower, but the perceived responsiveness is fine at 500.

the-mikedavis · 2025-03-02T02:19:13Z

There's some extra context in the LSP issue tracker about whether you can support push and pull diagnostics simultaneously microsoft/language-server-protocol#1743. ~~It sounds like rust-analyzer's behavior currently is a bug.~~ It's also mentioned in comments after the pull diagnostic PR was merged: rust-lang/rust-analyzer#18404 (comment)

(Continuing in rust-lang/rust-analyzer#18709)

the-mikedavis · 2025-03-02T03:22:48Z

helix-term/src/handlers/diagnostics.rs

+        if event
+            .doc
+            .has_language_server_with_feature(LanguageServerFeature::PullDiagnostics)
+        {
+            let document_id = event.doc.id();
+            job::dispatch_blocking(move |editor, _| {
+                let Some(doc) = editor.document(document_id) else {
+                    return;
+                };
+
+                let language_servers =
+                    doc.language_servers_with_feature(LanguageServerFeature::PullDiagnostics);
+
+                for language_server in language_servers {
+                    pull_diagnostics_for_document(doc, language_server);
+                }
+            })
+        }


Here we should be able to call pull_diagnostics_for_document directly and avoid the extra job dispatch

for language_server in event .doc .language_servers_with_feature(LanguageServerFeature::PullDiagnostics) { pull_diagnostics_for_document(event.doc, language_server); }

the-mikedavis · 2025-03-02T15:02:56Z

helix-core/src/diagnostic.rs

+pub enum DiagnosticProvider {
+    PublishDiagnosticProvider(LanguageServerId),
+    PullDiagnosticProvider(LanguageServerId),
+}


From the discussions I've read it sounds like this is meant to be done with the identifier value included on the server capabilities. R-a should add one in a future version rust-lang/rust-analyzer#19266

So instead what I'm thinking for this enum is

pub enum DiagnosticProvider { Lsp { server_id: LanguageServerId, identifier: Option<String>, }, // In the future, other non-LSP providers like spell checking go here... }

where pull diagnostics would use that field from the capabilities and push diagnostics would always be None. (At least for now - the LSP spec could add an identifier to push diagnostics in the future.)

the-mikedavis · 2025-03-02T15:13:34Z

helix-term/src/handlers/diagnostics.rs

+                })
+                .await
+            }
+            Err(err) => log::error!("Pull diagnostic request failed: {err}"),


I believe we should also handle the error case here and look for ServerCancelled and retry based on the cancellation data: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticServerCancellationData

Lack of cancel+retry support for this seems to have bit the neovim+rust-analyzer combination lately: neovim/neovim#30985 / neovim/neovim#31345. I can reproduce getting some error logs from this line about the server cancelling the request when modifying a document shortly after opening a rust file (starting rust-analyzer)

the-mikedavis · 2025-03-02T15:28:03Z

helix-term/src/handlers/diagnostics.rs

+fn handle_pull_diagnostics_response(
+    editor: &mut Editor,
+    response: lsp::DocumentDiagnosticReport,
+    provider: DiagnosticProvider,
+    uri: Uri,
+    document_id: DocumentId,
+) {
+    let Some(doc) = editor.document_mut(document_id) else {
+        return;
+    };
+
+    match response {
+        lsp::DocumentDiagnosticReport::Full(report) => {
+            // Diagnostic for requested file
+            editor.handle_lsp_diagnostics(
+                provider,
+                uri,
+                None,
+                report.full_document_diagnostic_report.items,
+                report.full_document_diagnostic_report.result_id,
+            );
+
+            // Diagnostic for related files
+            handle_document_diagnostic_report_kind(
+                editor,
+                document_id,
+                report.related_documents,
+                provider,
+            );
+        }
+        lsp::DocumentDiagnosticReport::Unchanged(report) => {
+            doc.previous_diagnostic_id =
+                Some(report.unchanged_document_diagnostic_report.result_id);
+
+            handle_document_diagnostic_report_kind(
+                editor,
+                document_id,
+                report.related_documents,
+                provider,
+            );
+        }
+    }
+}
+
+fn handle_document_diagnostic_report_kind(
+    editor: &mut Editor,
+    document_id: DocumentId,
+    report: Option<HashMap<lsp::Url, lsp::DocumentDiagnosticReportKind>>,
+    provider: DiagnosticProvider,
+) {
+    for (url, report) in report.into_iter().flatten() {
+        match report {
+            lsp::DocumentDiagnosticReportKind::Full(report) => {
+                let Ok(uri) = Uri::try_from(url) else {
+                    return;
+                };
+
+                editor.handle_lsp_diagnostics(provider, uri, None, report.items, report.result_id);
+            }
+            lsp::DocumentDiagnosticReportKind::Unchanged(report) => {
+                let Some(doc) = editor.document_mut(document_id) else {
+                    return;
+                };
+                doc.previous_diagnostic_id = Some(report.result_id);
+            }
+        }
+    }


I think we can eliminate the extra helper function here and make this a bit shorter

fn handle_pull_diagnostics_response( editor: &mut Editor, response: lsp::DocumentDiagnosticReport, provider: DiagnosticProvider, uri: Uri, document_id: DocumentId, ) { let (result_id, related_documents) = match response { lsp::DocumentDiagnosticReport::Full(report) => { editor.handle_lsp_diagnostics( provider, uri, None, report.full_document_diagnostic_report.items, ); ( report.full_document_diagnostic_report.result_id, report.related_documents, ) } lsp::DocumentDiagnosticReport::Unchanged(report) => ( Some(report.unchanged_document_diagnostic_report.result_id), report.related_documents, ), }; if let Some(doc) = editor.document_mut(document_id) { doc.previous_diagnostic_id = result_id; }; for (url, report) in related_documents.into_iter().flatten() { let result_id = match report { lsp::DocumentDiagnosticReportKind::Full(report) => { let Ok(uri) = Uri::try_from(url) else { continue; }; editor.handle_lsp_diagnostics(provider, uri, None, report.items); report.result_id } lsp::DocumentDiagnosticReportKind::Unchanged(report) => Some(report.result_id), }; if let Some(doc) = editor.document_mut(document_id) { doc.previous_diagnostic_id = result_id; } } }

I think we should also try to apply as much of the report (continue rather than return).

I also changed the signature of Editor::handle_lsp_diagnostics here so that the calling code here sets the result_id rather than passing it. I think that makes the option handling a little cleaner and we don't need to worry about the meaning of this field for push diagnostics.

Instead of passing the result_id though I believe we will need to pass the identifier (or at least the DiagnosticProvider).

the-mikedavis · 2025-03-02T15:48:45Z

helix-term/src/handlers/diagnostics.rs

+impl PullDiagnosticsHandler {
+    pub fn new() -> PullDiagnosticsHandler {
+        PullDiagnosticsHandler {
+            document_ids: [].into(),
+        }
+    }
+}
+
+impl helix_event::AsyncHook for PullDiagnosticsHandler {
+    type Event = PullDiagnosticsEvent;
+
+    fn handle_event(
+        &mut self,
+        event: Self::Event,
+        existing_debounce: Option<tokio::time::Instant>,
+    ) -> Option<tokio::time::Instant> {
+        if existing_debounce.is_none() {
+            dispatch_pull_diagnostic_for_document(event.document_id);
+        }
+
+        self.document_ids.insert(event.document_id);
+        Some(Instant::now() + Duration::from_millis(500))
+    }
+
+    fn finish_debounce(&mut self) {
+        for document_id in self.document_ids.clone() {
+            dispatch_pull_diagnostic_for_document(document_id);
+        }
+    }
+}


For the handler I think we will want some more nuanced logic. There are some tips at the bottom of the "Diagnostics Refresh" section in the spec that I think are meant to apply to pull diagnostics generally and are just out of place in the spec at the moment:

Implementation Considerations

Generally the language server specification doesn’t enforce any specific client implementation since those usually depend on how the client UI behaves. However since diagnostics can be provided on a document and workspace level here are some tips:

a client should pull actively for the document the users types in.

if the server signals inter file dependencies a client should also pull for visible documents to ensure accurate diagnostics. However the pull should happen less frequently.

if the server signals workspace pull support a client should also pull for workspace diagnostics. It is recommended for clients to implement partial result progress for the workspace pull to allow servers to keep the request open for a long time. If a server closes a workspace diagnostic pull request the client should re-trigger the request.

So the behavior should depend on whether the server declares that the language has inter-file dependencies. For language servers with inter-file dependencies we want to query for all "visible" documents attached to that language server. And for languages without inter-file dependencies we can request diagnostics only when that document changes, and we can pull on a lower debounce.

As for what is a "visible" document I think it's meant to be left up to the editor. In our case I think it's fine to query any open document (so we could look at Editor's documents instead of holding a hashset here).

So the behavior should depend on whether the server declares that the language has inter-file dependencies. For language servers with inter-file dependencies we want to query for all "visible" documents attached to that language server. And for languages without inter-file dependencies we can request diagnostics only when that document changes, and we can pull on a lower debounce.

I think this would require two separate async hooks: One for servers with and without interfile dependencies. Is this something we want?

As for what is a "visible" document I think it's meant to be left up to the editor. In our case I think it's fine to query any open document (so we could look at Editor's documents instead of holding a hashset here).

I think this requires that i add Editor to the DocumentDidChange and DocumentDidOpen in helix-view/src/events.rs. Not that this is a problem, it will just require a lot of changes

SofusA marked this pull request as ready for review August 3, 2024 20:49

SofusA force-pushed the pull-diagnostics branch from dbed6e4 to 13f048b Compare August 3, 2024 20:56

the-mikedavis reviewed Aug 4, 2024

View reviewed changes

rust-toolchain.toml Outdated Show resolved Hide resolved

helix-term/src/commands/lsp.rs Outdated Show resolved Hide resolved

helix-term/src/ui/editor.rs Outdated Show resolved Hide resolved

the-mikedavis added the A-language-server Area: Language server client label Aug 4, 2024

SofusA force-pushed the pull-diagnostics branch 2 times, most recently from 85600d2 to 29c5318 Compare August 4, 2024 18:37

archseer requested changes Aug 9, 2024

View reviewed changes

helix-term/src/handlers/diagnostics.rs Outdated Show resolved Hide resolved

helix-term/src/handlers/diagnostics.rs Outdated Show resolved Hide resolved

archseer requested a review from pascalkuthe August 9, 2024 10:34

the-mikedavis reviewed Aug 9, 2024

View reviewed changes

helix-view/src/handlers/lsp.rs Outdated Show resolved Hide resolved

SofusA force-pushed the pull-diagnostics branch from ac7aabf to 9e667bd Compare August 15, 2024 18:29

This comment was marked as duplicate.

Sign in to view

SofusA force-pushed the pull-diagnostics branch 5 times, most recently from 97a7124 to 32b2077 Compare August 16, 2024 18:14

SofusA requested review from archseer and the-mikedavis August 17, 2024 06:08

SofusA force-pushed the pull-diagnostics branch from 32b2077 to 1df9b76 Compare August 17, 2024 09:26

SofusA force-pushed the pull-diagnostics branch from 1df9b76 to 4177ba6 Compare August 17, 2024 16:44

SofusA force-pushed the pull-diagnostics branch 2 times, most recently from 70daf02 to 44c5453 Compare August 17, 2024 17:47

SofusA force-pushed the pull-diagnostics branch from fc2895b to 74a9e9e Compare December 27, 2024 18:07

SofusA force-pushed the pull-diagnostics branch from 74a9e9e to 69025dd Compare January 5, 2025 19:53

SofusA force-pushed the pull-diagnostics branch 2 times, most recently from fec66f2 to 19f7d64 Compare January 20, 2025 07:14

SofusA force-pushed the pull-diagnostics branch 3 times, most recently from e8957a5 to 3304a54 Compare January 27, 2025 07:24

the-mikedavis force-pushed the pull-diagnostics branch from 3304a54 to 3fb3904 Compare February 4, 2025 15:46

SofusA force-pushed the pull-diagnostics branch 3 times, most recently from 981b505 to 28e3cac Compare February 21, 2025 12:32

SofusA force-pushed the pull-diagnostics branch from 2053a6a to 2154e19 Compare February 22, 2025 16:23

SofusA force-pushed the pull-diagnostics branch from 2154e19 to 708d8f9 Compare February 22, 2025 18:36

SofusA force-pushed the pull-diagnostics branch 3 times, most recently from 21bd5a9 to 46b6ddf Compare February 25, 2025 05:01

SofusA added 2 commits February 27, 2025 04:55

Pull diagnostics

67db4c6

Separate publish and pull diagnostic provider

0a9b068

SofusA force-pushed the pull-diagnostics branch from 46b6ddf to 0a9b068 Compare February 27, 2025 03:55

the-mikedavis reviewed Mar 2, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support textDocument/diagnostic specification (Pull diagnostics) #11315

Support textDocument/diagnostic specification (Pull diagnostics) #11315

SofusA commented Jul 25, 2024 •

edited

Loading

SofusA commented Aug 12, 2024 •

edited

Loading

SofusA commented Aug 13, 2024 •

edited

Loading

SofusA commented Aug 13, 2024 •

edited

Loading

SofusA commented Aug 15, 2024 •

edited

Loading

This comment was marked as duplicate.

lizclipse commented Aug 17, 2024

SofusA commented Aug 17, 2024 •

edited

Loading

lizclipse commented Aug 18, 2024

SofusA commented Aug 18, 2024 •

edited

Loading

the-mikedavis commented Feb 4, 2025 •

edited

Loading

SofusA commented Feb 4, 2025

the-mikedavis commented Feb 4, 2025

SofusA commented Feb 10, 2025 •

edited

Loading

the-mikedavis commented Feb 10, 2025

SofusA commented Feb 21, 2025

SofusA commented Feb 22, 2025

SofusA commented Feb 22, 2025

the-mikedavis commented Mar 2, 2025 •

edited

Loading

the-mikedavis Mar 2, 2025

the-mikedavis Mar 2, 2025

the-mikedavis Mar 2, 2025

the-mikedavis Mar 2, 2025

the-mikedavis Mar 2, 2025

SofusA Mar 4, 2025

Support textDocument/diagnostic specification (Pull diagnostics) #11315

Are you sure you want to change the base?

Support textDocument/diagnostic specification (Pull diagnostics) #11315

Conversation

SofusA commented Jul 25, 2024 • edited Loading

SofusA commented Aug 12, 2024 • edited Loading

SofusA commented Aug 13, 2024 • edited Loading

SofusA commented Aug 13, 2024 • edited Loading

SofusA commented Aug 15, 2024 • edited Loading

This comment was marked as duplicate.

lizclipse commented Aug 17, 2024

SofusA commented Aug 17, 2024 • edited Loading

lizclipse commented Aug 18, 2024

SofusA commented Aug 18, 2024 • edited Loading

the-mikedavis commented Feb 4, 2025 • edited Loading

SofusA commented Feb 4, 2025

the-mikedavis commented Feb 4, 2025

SofusA commented Feb 10, 2025 • edited Loading

the-mikedavis commented Feb 10, 2025

SofusA commented Feb 21, 2025

SofusA commented Feb 22, 2025

SofusA commented Feb 22, 2025

the-mikedavis commented Mar 2, 2025 • edited Loading

the-mikedavis Mar 2, 2025

Choose a reason for hiding this comment

the-mikedavis Mar 2, 2025

Choose a reason for hiding this comment

the-mikedavis Mar 2, 2025

Choose a reason for hiding this comment

the-mikedavis Mar 2, 2025

Choose a reason for hiding this comment

the-mikedavis Mar 2, 2025

Choose a reason for hiding this comment

SofusA Mar 4, 2025

Choose a reason for hiding this comment

SofusA commented Jul 25, 2024 •

edited

Loading

SofusA commented Aug 12, 2024 •

edited

Loading

SofusA commented Aug 13, 2024 •

edited

Loading

SofusA commented Aug 13, 2024 •

edited

Loading

SofusA commented Aug 15, 2024 •

edited

Loading

SofusA commented Aug 17, 2024 •

edited

Loading

SofusA commented Aug 18, 2024 •

edited

Loading

the-mikedavis commented Feb 4, 2025 •

edited

Loading

SofusA commented Feb 10, 2025 •

edited

Loading

the-mikedavis commented Mar 2, 2025 •

edited

Loading