Proposal: add RequestDefinition and RequestImplementation helpers to powernap/pkg/lsp

[keakon]

Hi! I’d like to propose a small LSP client API addition in powernap/pkg/lsp.

Motivation

powernap already exposes a few high-level LSP request helpers such as:

• RequestHover
• FindReferences
• RequestCompletion

But it does not currently expose helpers for:

• textDocument/definition
• textDocument/implementation

This makes downstream clients fall back to either:

• patching powernap, or
• reimplementing lower-level request plumbing just to reach these two standard LSP operations.

In practice, definition and implementation are high-value semantic navigation primitives, especially for coding-agent / editor-like use cases.

Current state

From what I can see, most of the protocol groundwork already exists:

• MethodTextDocumentDefinition is already defined
• generated protocol types already include:
  • DefinitionParams
  • ImplementationParams
  • Or_Result_textDocument_definition
  • Or_Result_textDocument_implementation
• client capabilities already advertise definition
• implementation capability types also exist in the generated protocol package

So the missing piece seems to be mainly the exported request helpers in the high-level LSP client.

Proposed API

Add two methods to pkg/lsp.Client:

func (c *Client) RequestDefinition(
    ctx context.Context,
    uri string,
    position protocol.Position,
) (*protocol.Or_Result_textDocument_definition, error)

func (c *Client) RequestImplementation(
    ctx context.Context,
    uri string,
    position protocol.Position,
) (*protocol.Or_Result_textDocument_implementation, error)

These would mirror the existing style of RequestHover, and keep the full protocol result shape instead of forcing a lossy normalization in powernap.

Capability update

I’d also propose advertising implementation client capability during initialize, similar to definition:

"implementation": map[string]any{
    "dynamicRegistration": true,
    "linkSupport":         true,
}

Why this shape

I considered whether a generic exported Call(...) API would be better, but I think dedicated request helpers are a smaller and safer public API surface:

• they match the existing client style
• they avoid exposing lower-level transport details
• they make common LSP operations easy to use downstream

Compatibility

This would be a purely additive change:

• no breaking API changes
• no behavior changes for existing callers
• only new helper methods + capability advertisement