The @danielx/civet-monaco wrapper currently registers four Monaco providers — semantic tokens, hover, definition, and completion. PR #2069 adds eight new LSP handlers on the server side (signatureHelp, prepareRename, documentHighlight, typeDefinition, implementation, foldingRange, selectionRange, linkedEditingRange), but the Monaco wrapper has no corresponding register* adapters, so none of those features surface in Monaco-hosted editors that consume this wrapper.
VS Code is unaffected: vscode-languageclient/node auto-negotiates standard LSP capabilities from serverCapabilities and routes requests transparently, so the VS Code extension needs no per-feature wiring. Monaco's monaco.languages.* providers, on the other hand, must be registered explicitly.
Work to do
Add registerCivet*Provider functions (and Civet*Client interfaces) in lsp/monaco/source/monaco.civet mirroring the existing hover/definition pattern:
registerCivetLspProviders should be extended to register the new providers, with a correspondingly extended CivetLspProviderClient intersection. Each new adapter needs unit tests in lsp/monaco/test/monaco.civet to keep the 100% coverage gate.
Why a separate issue
The Monaco additions roughly double the wrapper's surface area, and review for the adapter pattern (type conversions, error handling, dispose semantics) is independent of the server-side delegation work in #2069. Splitting keeps each PR focused.
Context: this was raised by @edemaine on #2069.
The
@danielx/civet-monacowrapper currently registers four Monaco providers — semantic tokens, hover, definition, and completion. PR #2069 adds eight new LSP handlers on the server side (signatureHelp, prepareRename, documentHighlight, typeDefinition, implementation, foldingRange, selectionRange, linkedEditingRange), but the Monaco wrapper has no correspondingregister*adapters, so none of those features surface in Monaco-hosted editors that consume this wrapper.VS Code is unaffected:
vscode-languageclient/nodeauto-negotiates standard LSP capabilities fromserverCapabilitiesand routes requests transparently, so the VS Code extension needs no per-feature wiring. Monaco'smonaco.languages.*providers, on the other hand, must be registered explicitly.Work to do
Add
registerCivet*Providerfunctions (andCivet*Clientinterfaces) inlsp/monaco/source/monaco.civetmirroring the existing hover/definition pattern:registerCivetSignatureHelpProvider→monaco.languages.registerSignatureHelpProviderregisterCivetDocumentHighlightProvider→registerDocumentHighlightProviderregisterCivetTypeDefinitionProvider→registerTypeDefinitionProviderregisterCivetImplementationProvider→registerImplementationProviderregisterCivetFoldingRangeProvider→registerFoldingRangeProviderregisterCivetSelectionRangeProvider→registerSelectionRangeProviderregisterCivetLinkedEditingRangeProvider→registerLinkedEditingRangeProviderregisterCivetRenameProvider→registerRenameProvider(covers bothprovideRenameEditsfrom the existingonRenameRequesthandler andresolveRenameLocationfrom the newonPrepareRename; the prepareRename half can't be exposed alone — Monaco requiresprovideRenameEditson the same provider)registerCivetLspProvidersshould be extended to register the new providers, with a correspondingly extendedCivetLspProviderClientintersection. Each new adapter needs unit tests inlsp/monaco/test/monaco.civetto keep the 100% coverage gate.Why a separate issue
The Monaco additions roughly double the wrapper's surface area, and review for the adapter pattern (type conversions, error handling, dispose semantics) is independent of the server-side delegation work in #2069. Splitting keeps each PR focused.
Context: this was raised by @edemaine on #2069.