Metals serves one build per workspace folder, and Serena sends only the
repository root. Where the builds live below the root, Metals falls back to
its own search (BuildTools.searchForBuildTool), which looks one level down
and takes the *first* match — so in a monorepo every build but that one is
served with no build target, and cross-file references silently come back
empty.
Detect the build roots instead and send them all, one Metals service each.
`ls_specific_settings.scala.project_roots` names them explicitly where the
detection guesses wrong, `project_root_scan_depth` bounds the search.
The configured `ls_workspace_folders` are not usable for this: they are about
what SolidLSP indexes and are shared by every language server of a project, so
in a polyglot monorepo no single value suits both Metals and, say, tsserver.
Where the repository root is itself a build root, nothing changes.
The Nextflow language server schedules a debounced (1s) AST update on every
didOpen/didChange, and LanguageService.references is the only request that does
not await it -- documentSymbol, codeLens, documentLink and semanticTokensFull
all do. A references request issued inside that window races the recompile of
the file it asks about and can return an empty list, which is what the macOS CI
runner hit. Send a documentSymbol request for the same file first, which blocks
server-side until the pending update has been applied.
Also compare reference paths using the platform separator in the tests, since
relativePath is OS-native and the hardcoded forward slashes failed on Windows.
* scala: answer Metals' build-import prompt
Metals asks, via window/showMessageRequest, whether to import a workspace it
has not seen before. Serena registered no handler, so the request came back
`method 'window/showMessageRequest' not handled on client` and Metals logged
"Unexpected error initializing server" and gave up. No build server, no build
target, and every cross-file query answered by the fallback presentation
compiler — which cannot see past the file it is given.
A client cannot decline the question instead: Metals' `disableShowMessageRequest`
is server-side configuration, and its no-op fallback answers "Not now", which
imports nothing either. Answering is the only route to a build.
So answer the three prompts that lead to a build server, and dismiss anything
else with `null` — a prompt we do not recognise is one whose consequences we
cannot judge, and two of Metals' others offer to kill a process and to open a
window. "Don't show again" is never chosen; Metals persists that in the
project's own state.
Since answering yes lets Metals run the project's build tool,
`ls_specific_settings.scala.auto_import_build: false` declines instead.
* scala: name the build-tool choice as a gap, and test the setting
`Messages.ChooseBuildTool` ("Multiple build definitions found. Which would
you like to use?") offers the build tools' own executable names, and precedes
the import prompt wherever a workspace holds more than one kind of build. It
is dismissed like anything else unrecognised, so such a workspace is still
not imported — a deliberate choice, since picking one is a guess of a
different order, but one the comment and the setup guide should admit to
rather than claim every prompt on the path is answered.
Also: cover the route from `ls_specific_settings` to `auto_import_build`,
which nothing exercised, and correct the `ImportBuildChanges` message in the
fixtures, which had the notification variant's trailing full stop rather than
the request's own text.
* feat(kotlin): update language server to 262.9593.0
Note: download URL structure differs depending on version
---------
Co-authored-by: Dominik Jain <dominik.jain@oraios-ai.de>
Add a Deno language server backed by the Deno CLI's built-in `deno lsp`,
serving TypeScript/JavaScript in Deno projects. Unlike the plain
typescript-language-server it understands Deno module resolution
(npm:/jsr:/https: imports) and the `Deno.*` global namespace.
It is experimental and must be selected explicitly via
`language_servers: [deno]`; it overlaps the TypeScript server on file
extensions, so it is not auto-detected. Requires the `deno` CLI on PATH.
Tests run in CI: the `deno` marker joins the other-langs batch, which now
installs Deno via denoland/setup-deno. Off-CI and wherever the CLI is
absent they skip through the central conftest guard, following the existing
pattern for toolchain-gated language servers. Hover is covered explicitly,
including hover on a `Deno.*` global, which is the capability this server
adds over the TypeScript one.
SolidLanguageServer.create previously defaulted timeout=None, so Request
waits were unbounded. Test construction never set a timeout; a wedged
language server (intermittent ccls hang during indexing) could stall CI
until the job cap.
Default create to DEFAULT_LS_REQUEST_TIMEOUT (300s). Explicit timeout=None
still opts out. Project continues to pass ls_timeout from tool_timeout.
Resolves#1717
Co-authored-by: Dominik Jain <dominik.jain@oraios-ai.de>
The tray manager creates the shared NSApplication so that pystray can
attach its status item to it, but it never sets an activation policy.
The default is NSApplicationActivationPolicyRegular, which makes the
process a regular app: a Python icon appears in the Dock and in the
app switcher even though the tray manager has no windows.
Set NSApplicationActivationPolicyAccessory instead, which is the
policy intended for menu-bar-only agents. Only the status item remains
visible.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Tools that explicitly target a single file (`create_text_file`, `read_file`, `replace_content`) no longer
consider ignored paths in general, i.e. all files can be accessed.
When a path is explicitly accessed, we should not try to prevent it; the agent is assumed to have a good reason
for doing so.
- Tools that traverse a subtree of the project (`list_dir`, `find_file`, `search_for_pattern`) now all have an
option `skip_ignored_files` (whether to skip ignored sub-paths).
Note that if the base path is itself ignored, ignored paths cannot be considered.
Resolves#1805
`workspace/inlayHints/refresh` (plural) is not a method in the LSP
specification — the refresh request is `workspace/inlayHint/refresh`.
The handler could therefore never be invoked, so the request it was
meant to absorb would still be answered with `MethodNotFound`.
The Kotlin language server client advertises `refreshSupport` for
codeLens, semanticTokens, inlineValue, inlayHint and diagnostics, but
registered no handler for the corresponding `workspace/*/refresh`
requests.
When the server sends one, `LanguageServerProcess._request_handler`
finds no handler and replies with `MethodNotFound`. The Kotlin LSP
treats that error as fatal and terminates, which surfaces as
`LanguageServerTerminatedException` and kills any in-flight tool call.
Register no-op handlers for all five advertised capabilities, mirroring
what `svelte_language_server` already does.
Dominik Jain