feat: document LSP and Neovim support on the front page - #226
Merged
Conversation
Adds an "Any Editor, via LSP" section after the Visual Studio Code one, covering the `flix lsp` command -- which starts the language server on stdin/stdout -- with a Neovim config snippet alongside it. The framing is that the compiler is the language server, so there is no separate indexer to drift from `flix build`. Also retitles the neighbouring section to "Visual Studio Code" so the two headings read as a pair, adds LSP to the complete feature list, and expands the FAQ answer, which previously said only that generic LSP support exists without naming the command or any editor. Leaves a gated placeholder for a Neovim capture: set `neovimShot` to the file's path once the screenshot exists, and the figure renders itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaces the init.lua snippet with a screenshot of a Flix buffer in Neovim, which demonstrates the claim rather than restating it; the book already covers setup editor by editor, so the config is a duplicate. The capture sits bare in the column rather than in a .card. It is a picture of a window and carries its own border and 24px corners, so a card would trace a second outline at a 6px radius across them. No .plate either: it was taken in a dark theme and its corners are transparent, so it wants the page under it rather than a white ground it would then have to sit on in dark mode. Also shortens the parity sentence to say VSCode, which is what the rest of the page calls it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
magnus-madsen
marked this pull request as ready for review
August 11, 2026 14:24
The sentence promises that pointing a client at `flix lsp` is all it takes, and that is not true for Zed: per its docs a new language must be defined inside a Zed extension, which implements `language_server_command` in Rust. There is no settings entry that points it at an arbitrary server. Leaves Neovim, Emacs, and Helix, which do reach the server from config alone, and which happen to span three kinds of editor rather than three points on a trend line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The clause read "the editor and `flix build` can never disagree about your code". Naming the build first matches the direction of the claim -- the compiler is the thing the editor is being measured against -- and "about your code" was carrying no weight, since there is nothing else the two could disagree about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The parity sentence listed types, effects, errors, and completions, which undersells it. Every item in the longer list -- inline diagnostics, hovers, completions, signature help, jump-to-definition, find-references, rename, and quick fixes -- is registered by mkServerCapabilities in the plain server, not just in the VSCode one, so none of it is a claim that holds only for the extension. Semantic highlighting is scoped rather than listed flat: the server advertises semantic tokens, but whether they surface is up to the client. Neovim requests them, which is what the capture beside this text shows; Helix and Eglot have no semantic token support today. Inlay hints stay off the list deliberately. The server implements the request but never calls setInlayHintProvider, so clients do not ask. Also widens the heading to "Any Text Editor", and says the book covers editor configuration rather than setup editor by editor, here and in the matching FAQ answer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The list is language features -- what the compiler accepts and how it compiles it -- and LSP is neither. It also sat oddly beside the entries around it, between JVM bytecode and tail call elimination, and pushed the third column to eleven items against ten in the other two. The section above already makes the point at length, so nothing is lost by removing the line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an Any Text Editor, via LSP section to the front page, after the Visual Studio Code one.
The framing is that the compiler is the language server, so there is no separate indexer that can drift from
flix build. The command isflix lsp, which starts the server on stdin/stdout — confirmed againstMain.scala:608andLspServer.scala:49, which wires it toSystem.in/System.out. (lsp-vscode <port>is the VS Code-only TCP variant and is deliberately not documented here.)Changes
src/pages/index.astro— new section: prose plus a capture of a Flix buffer in Neovim; retitlesVisual Studio Code SupporttoVisual Studio Codeso the two headings read as a pair.public/images/neovim.png— the capture, 1100x668. It sits bare rather than in a.card, and without.plate: it is a picture of a window carrying its own border and 24px corners, and its corners are transparent, so it wants the page under it in both site themes.src/pages/faq.astro— the LSP answer previously said only that generic LSP support exists; it now names the command and the editors and links the book.What the sentence claims, and why
Every capability named on the page — inline diagnostics, hovers, completions, signature help, jump-to-definition, find-references, rename, quick fixes — is registered by
mkServerCapabilitiesinLspServer.scala:176-203, the plain server, not only the VS Code one. Diagnostics are pushed viapublishDiagnostics(LspServer.scala:253) rather than registered, so they work too.Semantic highlighting is scoped rather than listed flat ("wherever the editor supports it"): the server advertises semantic tokens, but surfacing them is up to the client. Neovim requests them, which is what the capture shows — there is no
tree-sitter-flixin any registry, so every colour in that buffer comes fromSemanticTokensProvider. Helix has no semantic token support (helix-editor/helix#9360, an open draft stale since 2024-01) and neither does Eglot (joaotavora/eglot#839, open since 2022).Resolved during review
language_server_commandin Rust, so "point your client at it and you are done" was not true for it. Neovim, Emacs, and Helix all reach the server from config alone.init.luasnippet was replaced by the screenshot (cf4ce01) — it demonstrates the claim rather than restating it, and the book already covers editor configuration.Possible upstream bug, not fixed here
Inlay hints never reach non-VS-Code clients.
LspServer.scala:419overridesinlayHintand callsInlayHintProvider, butmkServerCapabilitiesnever callssetInlayHintProvider. Clients gate requests on advertised capabilities, so Neovim, Helix, and Emacs will not ask and the hints never appear. Inlay Hints are listed as a feature in the VS Code section of this page, so this is why they are deliberately absent from the LSP list. Worth an issue againstflix/flixif it is an oversight.Verified with
npm run buildandnpm run checkat each step — 0 errors, 0 warnings.🤖 Generated with Claude Code