aspnetcore

Go to file

N. Taylor Mullen d69938f36d Initialize LSP documents earlier. - Prior to this we would start tracking LSP documents when an `ITextView` was associated with our `ITextBuffer`. The issue with this is when the `ILanguageClient` infrastructure initializes itself before we do and starts our `LanguageServer` it's we start retrieving requests that require access to our `LSPDocumentManager`. That's an issue because our `LSPDocumentManager` may not have been initialized yet resulting in failure to fulfill requests. - Changed how we initialize `ITextBuffer`s. Before we were setting up all of the logic to change the content type of a text buffer and populate its properties at the `EditorFactory` layer; however, how we were doing it (waiting for the ITextBuffer to load) resulted in `ITextDocumentListener` events firing prior to our content type changes would occur. This is a problem becasue the `ILanguageaClient` infrastructure will start making its decision to turn on LSP features for your `ITextBuffer` at the point and time. Now we change the `ITextBuffer`s content type (and set properties) during the `ITextDocumentListener` created pipeline. This resulted in almost all of our logic in our editor factory to be split out into two classes. 1. `LSPEditorFeatureDetector`, we needed to be able to detect the "enabledness" of features in two locations. Once at the `EditorFactory` layer to ensure we know when to disallow other editor factories participation in the `ITextBuffer` creation and a second at the `ITextDocumentListener` layer when we inspect an `ITextDocument` and need to determine if we want to "initialize" it (change its content type etc.). 2. `RazorLSPTextDocumentCreatedListener`, this is our `ITextDocumentListener` i've been referring to. It now houses the logic on how to change the content type and populate the `ITextBuffer`'s properties. - Changed our `LSPDocumentManager` to no longer depend on `ITextView`s for ref counting documents. Instead we just take an `ITextBuffer` and keep an internal count of how many times we've been asked to track a document. In practice this number never goes past 1 however it doesn't hurt to be defensive. - Added IVT from CodeAnalysis.Razor to our LanguageServerClient project in order to enable the retrieval of our `FilePathComparison` type. - Given the new refactoring of our feature detector and the `ITextDocumentListener` pieces I was able to add extensive testing to ensure all things work as expected. Fixes dotnet/aspnetcoredotnet/aspnetcore-tooling#19160 \n\nCommit migrated from `d0a7dfce09`	2020-03-02 20:09:03 -08:00
src	Initialize LSP documents earlier.	2020-03-02 20:09:03 -08:00

N. Taylor Mullen d69938f36d Initialize LSP documents earlier.

- Prior to this we would start tracking LSP documents when an `ITextView` was associated with our `ITextBuffer`. The issue with this is when the `ILanguageClient` infrastructure initializes itself before we do and starts our `LanguageServer` it's we start retrieving requests that require access to our `LSPDocumentManager`. That's an issue because our `LSPDocumentManager` may not have been initialized yet resulting in failure to fulfill requests.
- Changed how we initialize `ITextBuffer`s. Before we were setting up all of the logic to change the content type of a text buffer and populate its properties at the `EditorFactory` layer; however, how we were doing it (waiting for the ITextBuffer to load) resulted in `ITextDocumentListener` events firing prior to our content type changes would occur. This is a problem becasue the `ILanguageaClient` infrastructure will start making its decision to turn on LSP features for your `ITextBuffer` at the point and time. Now we change the `ITextBuffer`s content type (and set properties) during the `ITextDocumentListener` created pipeline.

This resulted in almost all of our logic in our editor factory to be split out into two classes.
  1. `LSPEditorFeatureDetector`, we needed to be able to detect the "enabledness" of features in two locations. Once at the `EditorFactory` layer to ensure we know when to disallow other editor factories participation in the `ITextBuffer` creation and a second at the `ITextDocumentListener` layer when we inspect an `ITextDocument` and need to determine if we want to "initialize" it (change its content type etc.).
  2. `RazorLSPTextDocumentCreatedListener`, this is our `ITextDocumentListener` i've been referring to. It now houses the logic on how to change the content type and populate the `ITextBuffer`'s properties.

- Changed our `LSPDocumentManager` to no longer depend on `ITextView`s for ref counting documents. Instead we just take an `ITextBuffer` and keep an internal count of how many times we've been asked to track a document. In practice this number never goes past 1 however it doesn't hurt to be defensive.
- Added IVT from CodeAnalysis.Razor to our LanguageServerClient project in order to enable the retrieval of our `FilePathComparison` type.
- Given the new refactoring of our feature detector and the `ITextDocumentListener` pieces I was able to add extensive testing to ensure all things work as expected.

Fixes dotnet/aspnetcoredotnet/aspnetcore-tooling#19160
\n\nCommit migrated from d0a7dfce09

2020-03-02 20:09:03 -08:00

src Initialize LSP documents earlier. 2020-03-02 20:09:03 -08:00