Hello @padmashree06!
Thank you for your interest in this project! I reviewed your proposal along with @snprajwal. This is a really good start, but we have some suggestions for how it can be improved. In general, I would say that most of these features should be implemented in SourceKit-LSP so that we can get support across all editors rather than just VS Code.
Section 4.1: The approach you described for handling the documentation links won't work for all cases. The symbol search in VS Code is a workspace wide search and documentation links in DocC can be too vague to resolve by the name alone. Consider the following example:
/// A protocol for a test that specifies a ``type``.
protocol Test {
let type: String
}
In this example, your approach would perform a symbol search for type which, for the average repository, will have many many results with no way to distinguish which one we really want. It would be better to have SourceKit-LSP handle this when it performs symbol resolution on behalf of SwiftDocC because it knows that the documentation request was made for the Test protocol which contains a member called type. VS Code only knows the location of the cursor and the file that it sent to SourceKit-LSP. Have a look at the DocCReferenceResolutionService to see how SwiftDocC asks SourceKit-LSP to resolve references.
Section 4.2: We like the idea of showing an error if a link isn't valid. However, ideally SourceKit-LSP wouldn't show the link at all if it doesn't exist. We'd rather see see diagnostics in the editor and problems view if SourceKit-LSP cannot resolve symbols kind of like what you talk about in Section 4.5. That way a user doesn't have to click through all the links to see if they're valid. For example, the following code snippet should underline foobar in red and explain that the symbol could not be found:
/// A class that contains a property ``foobar``.
class Foo {
let bar: String
}
Section 4.3: Go to definition is part of the LSP specification and should be handled by SourceKit-LSP. SourceKit-LSP would also need to report symbols in Markdown/tutorial files as well as in-source documentation for this to work.
Section 4.6: This is a pretty cool idea. The only issue I see with your suggested solution is that we should get the content of the hover from SwiftDocC somehow instead of hardcoding it in SourceKit-LSP. That way there's less need to coordinate in the future between the two repos. I'm not sure if something like that already exists or needs to be added to SwiftDocC.
We'd be fine with making this a large project given the number of features. However, it's also possible to just pare down the scope a little bit. The three most important parts of this project are go to definition, diagnostics, and link navigation. The others can be set as stretch goals that won't impact the pass/failure status of the project. It's up to you on whether or not you want to commit to doing all of the proposed features.
Please let us know if you have any questions or if you update the proposal!