Add DocCSymbolLinkDefinition request - #76
Conversation
4789cd1 to
0c7eed9
Compare
ahoppen
left a comment
There was a problem hiding this comment.
Two high-level questions:
- Where does the editor get the symbol link from?
- Depending on how the editor extracts the symbol name, can’t SourceKit-LSP do it and thus can’t this be implemented using a
textDocument/definitionrequest?
|
ahoppen
left a comment
There was a problem hiding this comment.
Sounds reasonable to me then, just two small comments.
|
|
||
| public struct DocCSymbolLinkDefinitionRequest: TextDocumentRequest, Hashable { | ||
| public static let method: String = "sourcekit/textDocument/doccSymbolLinkDefinition" | ||
| public typealias Response = Location? |
There was a problem hiding this comment.
Should this be LocationsOrLocationLinksResponse? to match textDocument/definition? It would also allow us to return multiple locations in case the symbol link is ambiguous.
| /// This request is an extension to LSP supported by SourceKit-LSP. | ||
| /// The client is expected to navigate to the returned location, or display an appropriate error | ||
| /// message to the user if the response is `nil`. | ||
|
|
0c7eed9 to
03b2b27
Compare
|
I have made the changes! Thanks for the review! |
ahoppen
left a comment
There was a problem hiding this comment.
LGTM but want to review the corresponding LSP changes before merging this.
Summary
Adds
DocCSymbolLinkDefinitionRequest, a new LSP extension request that resolves a DocC symbol link string to the location of the symbol it refers to.Motivation
Currently, symbol links in the DocC Live Preview are not clickable. To enable this, we need a new request that adds the functionality of navigating to the symbol's definition if it exists, or showing an error when it doesn't - making the preview interactive.
Details
DocCSymbolLinkDefinitionRequesttakes the symbol link string and the document's URI as arguments and returns theLocationof where the symbol is defined.