[FEATURE]: Add LSP Inlay Hint support for better DSL editing experience

[iilitlleboyii]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Feature Request: Add LSP Inlay Hint Support

Summary

Please add support for the LSP textDocument/inlayHint method to enable inline code hints (parameter names, type hints, etc.) in OpenCode.

Problem

OpenCode currently lacks support for LSP Inlay Hints, which are essential for editing DSL (Domain Specific Language) files and improving code readability in general.

What are Inlay Hints?
Inlay Hints are inline annotations displayed directly in the code that show:

• Parameter names in function calls: console.log(message: "hello")
• Type annotations for variables: const value: string = getData()
• Return types: function foo(): number { ... }

My Use Case: AI Cannot Understand My Custom DSL Without Inlay Hints

I have developed a custom DSL language for automation testing. The language relies heavily on parameter names to convey meaning:

# Without Inlay Hints (what AI sees):
ACTION("open", "/login", true, 5000)

# With Inlay Hints (what should be displayed):
ACTION(method: "open", url: "/login", waitForLoad: true, timeout: 5000)

The Problem: When I use OpenCode's AI to help with my DSL scripts, the AI has no way to know that the second parameter is url, the third is waitForLoad, etc. The LSP server provides this information via inlay hints, but OpenCode doesn't consume them.

Impact: Without inlay hints, the AI cannot:

• Understand what each parameter represents
• Generate correct DSL code
• Explain the meaning of function calls
• Suggest meaningful refactorings

This severely limits OpenCode's usefulness for any DSL or language where parameter semantics matter.

Use Cases

1. AI Understanding DSL Code: Inlay hints provide crucial context that enables OpenCode's AI to correctly interpret and assist with custom DSL scripts.

2. DSL Language Support: Custom DSL files often have functions where parameter names indicate their purpose (e.g., TRANSFORM(mode: "append", value: "...")). Without inlay hints, users must constantly refer to documentation.

3. Improved Code Readability: Even for standard languages, inlay hints reduce the need to hover over functions to check parameter order and types.

4. Better Developer Experience: This is a standard LSP feature supported by VSCode, Neovim, IntelliJ, and other modern editors.

Proposed Implementation

Based on the existing LSP implementation in packages/opencode/src/lsp/index.ts, adding inlay hint support would involve:

export async function inlayHint(input: {
  file: string;
  range?: LSP.Range
}) {
  return run(input.file, (client) =>
    client.connection
      .sendRequest("textDocument/inlayHint", {
        textDocument: {
          uri: pathToFileURL(input.file).href,
        },
        range: input.range,
      })
      .catch(() => null)
  )
}

Display could be integrated into the TUI using inline text decoration or virtual text rendering.

References

• [LSP Specification: Inlay Hints](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_inlayHint)
• Similar implementations in other tools:
  • Neovim: vim.lsp.inlay_hint
  • VSCode: provideInlayHints API
  • coc.nvim: InlayHintsFeature

Priority

Medium-High (blocks effective DSL editing experience)

Additional Context

This would benefit not just DSL authors, but all users working with TypeScript, Rust, Python, and other languages where language servers provide inlay hints.

---

Tags: lsp, enhancement, tui, inlay-hints