fix(language): highlight .h headers as the language detection actually chose

[sinelaw]

Fixes #3009.

Two commits: the first makes .h headers highlight as the language detection already chose, the second makes that detection ask the file's own filesystem so it works over SSH.

What was happening

.h was unconditionally C, with no content or project-layout influence. The same bytes in widget.h and widget.hpp gave C and C++ in the status bar respectively, and in the .h buffer namespace, class, public, explicit, virtual, template, typename all rendered in plain foreground instead of the keyword colour — std::string even split as std: + : rather than scoping ::.

The interesting part is that a C++ promotion heuristic already existed and never reached the screen. detect_language (services/lsp/manager.rs) promotes .h to cpp when the surrounding tree smells like C++ — sibling C++ sources, or an ancestor compile_commands.json with a C++ marker. Measured against the unfixed build: a directory holding only widget.h and a sibling widget.cpp — precisely the signal that heuristic looks for — still opened the header as C.

DetectedLanguage::from_path_with_fallback was the reason. It computed config_lang_id from that promoting detect_language, then applied it through an override_name closure that touched d.name and nothing else, while highlighter, ts_language and display_name all came from registry.find_by_path, which resolves .h through the extension table (config.rs, languages.c.extensions = ["c", "h"]) and lands on C. So the LSP side could already believe a header was C++ while the grammar, the status-bar label and every colour on screen said C.

Commit 1 — let the chosen language id pick the grammar

primitives/detected_language.rs. override_name is replaced by DetectedLanguage::align_with_config_id: when detection resolved a config id, that id wins and the grammar is re-resolved through [languages.<id>].grammar. If the grammar name resolves to the same catalog entry — aliases, the common case — or to nothing, the path-resolved grammar is left untouched. One hash lookup; no buffer scan and no extra filesystem access.

User config still overrides in both directions — languages.cpp.extensions including "h" continues to force C++ globally, and a config without a cpp language leaves .h as C.

Commit 2 — ask the file's own filesystem

The probe deciding that promotion, header_in_cpp_tree, read the filesystem with std::fs directly — a standing violation of the FileSystem trait rule, carrying a NOTE(remote-fs) that said the fix needed threading &dyn FileSystem through detect_language and DetectedLanguage::from_path. Once commit 1 made the probe drive what the user sees, that became user-visible: on an SSH session the probe read the local filesystem, found nothing, and the promotion silently no-opped, so a .h in a remote C++ tree still highlighted as C.

The trait is now threaded through. All 11 non-test call sites of from_path/from_path_with_fallback were checked first: every one already holds the buffer it just loaded, so buffer.filesystem() answers at each and no call site needed an escape hatch. The parameter is a required &dyn FileSystem rather than an Option deliberately — an optional one would re-create exactly the failure being fixed, where a caller that omits it gets a silent "no" instead of a compile error.

Remote round trips are budgeted, not assumed cheap

RemoteFileSystem implements the whole sync FileSystem surface over AgentChannel::request_blocking — read_dir → ls, metadata → stat, read_range → read, one blocking SSH round trip each, on the single-threaded editor loop. That file already documents the hazard for $HOME lookups: a blocking request there "would hang the whole single-threaded UI for the full request timeout."

Threading the trait naively would therefore have put up to 13 serialized round trips on the file-open path. Instead the probe carries a ProbeBudget derived from fs.remote_connection_info():

• Remote — exactly one round trip, the sibling listing, which is the decisive signal and covers the ordinary widget.h / widget.cpp layout in this issue. The compile_commands.json ancestor walk is skipped.
• Local — unchanged: 11 directories, same 1 MiB cap.

The trade is explicit: a remote header under an include/-style tree with its sources elsewhere still reads as C. That is strictly better than today's unconditional no-op and does not buy highlighting with a frozen editor. The budget is a directory count rather than an if is_remote inside the loop, so the expensive case is unrepresentable rather than merely unreached.

Two bugs the tests caught

• "clang++" does not contain the substring "c++" — the characters before ++ are g. The first fixture was unrealistic and a failing test said so.
• FileSystem::read_range is read_exact-shaped and errors on a short file, so a flat 1 MiB read would have made every normal-sized compile_commands.json read as "not C++". The clamp to min(size, 1 MiB) is load-bearing and has a test pinning it.

Not included: detect_workspace_root

The old NOTE asked for it in the same pass. It is not a mechanical substitution: its three call sites sit inside LSP spawn/initialize, LspManager has no filesystem to thread, and resolve_root_uri walks host paths on purpose before applying path_translation for devcontainers — so "which filesystem" is a genuine design question there. The NOTE has been rewritten to state that accurately rather than implying it was covered.

Tests

Commit 1: six unit tests in detected_language.rs (sibling promotion, pure-C project staying C, user config forcing h to C++, config without a cpp language, an alias resolving to the same entry, an unknown config grammar keeping the path-resolved highlighter) plus two e2e in tests/e2e/issue_3009_h_header_cpp.rs.

Commit 2, on a FakeTree fake filesystem (no shared in-memory double existed; it follows the delegation pattern in tests/e2e/explorer_bugs.rs): test_h_header_promotion_reads_injected_filesystem_not_local_disk, test_h_header_promotion_ignores_local_disk_when_injected_fs_says_c, test_remote_probe_spends_one_op_and_skips_ancestor_walk, test_local_probe_still_walks_ancestors_for_compile_commands, test_small_compile_commands_is_read_despite_the_one_mib_cap, test_non_header_paths_touch_no_filesystem, plus e2e test_remote_h_header_beside_cpp_source_highlights_as_cpp.

Verification status

Commit 1: unit tests verified both directions — 6 passed with the fix; with the re-resolution neutralized, test_h_header_beside_cpp_sibling_detects_cpp_grammar failed with left: "C" / right: "C++" and the other five passed. Its two e2e tests were run only with the fix, so their fails-without direction is unverified.

Commit 2: cargo test -p fresh-editor --lib -- detected_language detect_language jsonc_filenames workspace_root → 31 passed, 0 failed. Reverting the sibling scan to std::fs makes the three key unit tests fail and restoring it makes them pass. The single new e2e test was also run individually (not the suite): it passes, and with the probe reverted to std::fs it fails with the status bar reading C instead of C++.

Clean on the committed tree: cargo fmt --all --check, cargo check -p fresh-editor --all-targets, cargo clippy -p fresh-editor --all-targets (zero warnings in touched files; the rest are pre-existing), and cargo check --all-targets --features gui. Full e2e suites were left to CI. No plugin API or config type changes, so no .d.ts or schema regeneration, and no new i18n keys.

🤖 Generated with Claude Code

https://claude.ai/code/session_014RASTj1HKSpMtmL2ZpjJAN

[sinelaw]

Windows CI failure fixed (2817749). Ubuntu and macOS were already green; the single failure was test_remote_h_header_beside_cpp_source_highlights_as_cpp, one of the tests this PR adds.

The fix is in the test, not the production probe. The probe uses Path::parent, Path::extension, PathBuf::join and the injected FileSystem throughout — no string comparison, no case assumption. The platform-variant primitive was a hard-coded POSIX absolute literal in this PR's own fixture.

What actually diverged

Not the fake tree's lookups, Path::parent(), the extension check or the sibling scan — the probe is never reached at all.

Path::is_absolute on Windows requires a prefix (drive letter or UNC share) as well as a root. /remote-cpp-project/widget.h has components RootDir, Normal, Normal and no Prefix, so Windows considers it relative. The open path then re-anchors it (app/file_open_orchestrators.rs:1074):

let resolved_path = if path.is_relative() { base_dir.join(path) } else { path.to_path_buf() };

and since the fake filesystem reports a remote connection, base_dir is filesystem.home_dir() — the local home. So on Windows the header opened as C:\…\remote-cpp-project\widget.h, strip_prefix in the fake's mapping no longer matched, translation stopped, StdFileSystem found nothing, and the editor created an empty unsaved buffer. The status bar there most likely read Text, not even C.

Established without a Windows box, two ways: the documented std::path semantics ("a path is absolute if it has a prefix and starts with the root: c:\windows is absolute, while c:temp and \temp are not"), and an emulation on Linux — giving the fixture the one property the literal has on Windows, a root that is not absolute — which reproduced the re-anchor visibly:

status bar should report C++ for a header in a *remote* C++ tree. Got:  Trusted  user@build-host  Ln 1, Col 1    Opened /root/remote-cpp-project/widget.h     LF  UTF-8  Text  Palette: Ctrl+P

That /root/… prefix is home_dir() — the exact mechanism.

The change

The fake root is now constructed rather than written as a literal: take the leading Prefix/RootDir components of a path the platform itself produced (std::env::temp_dir()) and join "remote-cpp-project" onto them — /remote-cpp-project on Unix, C:\remote-cpp-project on Windows — with an assert!(root.is_absolute()) pinning the invariant. The test also now asserts the remote path does not resolve locally, so it states its own premise.

Still meaningful

With src/ reverted to master (reverting only the two production files does not compile — the PR threads &dyn FileSystem through eleven call sites — so the revert was a superset), the remote test still fails for the original reason:

panicked at issue_3009_h_header_cpp.rs:369:5:
status bar should report C++ for a header in a *remote* C++ tree. Got:  Trusted  user@build-host  Ln 1, Col 1    Opened /remote-cpp-project/wid...  LF  ASCII  C   LSP (off)   Palette: Ctrl+P

The path resolves correctly there and the label is C — so the portability fix did not weaken it into vacuity. All three issue_3009 tests pass on Linux with the fix.

One pre-existing issue found, deliberately not fixed

That same path.is_relative() branch means a real Windows client attached to a Linux SSH host would re-anchor every absolute remote path it is handed. Pre-existing, unrelated to #3009, untouched here. The codebase already knows the shape of it — services/terminal/term.rs:383 explicitly refuses Path::is_absolute() for this reason. Deciding what "absolute" means for a path whose owning host may run a different OS is a design question, not a mechanical fix — same category as the detect_workspace_root NOTE above.

Caveat: the Windows fix itself is unverified locally — this is a Linux box. What was verified is the mechanism (via the Linux emulation) and that the fix keeps Linux green while keeping the test failing without the production change. That the constructed root makes windows-latest pass rests on CI.

---

Generated by Claude Code