feat: Add configurable lsp timeout

[tjg184]

This is a proposal to allow timeouts to be set for LSPs at the specific server/LSP levels. Currently, there is a default timeout of 45 seconds, which is sometimes not long enough. As one example, in the kotlin-ls LSP, some projects are larger and could take longer than this to initialize.

This PR is attempting to allow a specific server timeout only.

An example is below showing overriding the kotlin-ls timeout.

{
  "$schema": "https://opencode.ai/config.json",
  "instructions": ["STYLE_GUIDE.md"],
  "provider": {
    "opencode": {
      "options": {},
    },
  },
  "lsp": {
    "kotlin-ls": {
      "timeout": 120000, 
    },
  },
}

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Results:

No duplicate PRs found. The search for "lsp timeout" and "configurable timeout" returned PR #6997 (the current PR) along with some tangentially related PRs, but none of them appear to be addressing the same feature:

• refactor: extract and modularize core system components #1294 - "refactor: extract and modularize core system components" - Infrastructure refactoring, not LSP timeout
• Add Nextflow LSP server integration #2618 - "Add Nextflow LSP server integration" - Adds a different LSP integration, not timeout configuration
• Process Tools for Interactive CLI commands #2483 - "Process Tools for Interactive CLI commands" - CLI tools, not LSP timeout
• Add configurable double-Esc interrupt window #5787 - "Add configurable double-Esc interrupt window" - Configurable interrupt behavior, different from LSP timeout

✅ Conclusion: PR #6997 appears to be a unique feature request for configurable LSP timeout with no existing duplicates.

[rekram1-node]

Adding timeout field to this makes sense:

      lsp: z
        .union([
          z.literal(false),
          z.record(
            z.string(),
            z.union([
              z.object({
                disabled: z.literal(true),
              }),
              z.object({
                command: z.array(z.string()),
                extensions: z.array(z.string()).optional(),
                disabled: z.boolean().optional(),
                env: z.record(z.string(), z.string()).optional(),
                initialization: z.record(z.string(), z.any()).optional(),
                timeout: .... // <<<<<<<<<<<<<<<<<< THIS HERE
              }),
            ]),
          ),
        ])

I dont really like that global version you did, I'd rather just make a flag

[tjg184]

Adding timeout field to this makes sense:

      lsp: z
        .union([
          z.literal(false),
          z.record(
            z.string(),
            z.union([
              z.object({
                disabled: z.literal(true),
              }),
              z.object({
                command: z.array(z.string()),
                extensions: z.array(z.string()).optional(),
                disabled: z.boolean().optional(),
                env: z.record(z.string(), z.string()).optional(),
                initialization: z.record(z.string(), z.any()).optional(),
                timeout: .... // <<<<<<<<<<<<<<<<<< THIS HERE
              }),
            ]),
          ),
        ])

I dont really like that global version you did, I'd rather just make a flag

Good call on removing the global timeout. Take a look at the change now. It's slightly different than what you suggested, as I believe just adding the timeout field would not allow someone to override a built-in server without specifying a command. With the proposed changes, it would allow a timeout to override a built-in server, along with a timeout for a custom server too. I tried to cover this with tests. The only thing I don't like is that the command is now optional (and I believe it has to be) since someone could just specify a timeout. I tried to catch this in the refine rules.

[rekram1-node]

why did we get rid of the union here? That union made some of the code nicer, now u need extra null checks everywhere...

[tjg184]

Well, that was a mistake. I corrected it.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.