Lumos Toolchain: Six Editors, One Weekend

You know what nobody tells you about building a new programming language? The language itself is maybe 30% of the work. The other 70%? Editor support. Syntax highlighting. LSP integration. Autocompletion. The stuff that makes developers actually want to use your thing.

I built Lumos to solve Rust↔TypeScript synchronization for Solana. But a language without editor support is just a fancy text file. Developers live in their editors. If typing files feels like writing raw assembly, nobody's gonna adopt it.

So after shipping the core compiler, I gave myself a challenge: full IDE support across every major editor. In one weekend.

The Tree-sitter Foundation

Smart move first: build the foundation that everything else depends on.

Tree-sitter is a parser generator that powers syntax highlighting in most modern editors. Write one grammar, get highlighting for Neovim, VSCode, Emacs, Sublime — basically everywhere.

The grammar took a full day. Lumos syntax looks like Rust but isn't quite Rust. Structs, enums, attributes like , type annotations. Each construct needed careful grammar rules. Test. Fail. Fix. Repeat about fifty times.

But once that grammar worked? Everything else became plug-and-play.

The Plugin Blitz

Day two. Six editors. Let's go.

Neovim () came first because that's my daily driver. Lua config, Tree-sitter integration, LSP client setup. The Lumos LSP server (written in Rust, shipped with the CLI) handles autocompletion, go-to-definition, error diagnostics. Neovim just connects to it.

VSCode () was straightforward — Microsoft's extension API is well-documented. TextMate grammar for highlighting, language server protocol for intelligence. Published to the marketplace same day.

IntelliJ () hurt. Kotlin, Gradle, JetBrains' custom APIs. But Rust Rover users deserve nice things too. Got it working by midnight.

Sublime Text () and Emacs () came fast after that. Sublime uses YAML-based syntax definitions. Emacs uses a major mode with font-lock rules. Both leverage the LSP server.

Six editors. Full syntax highlighting. Autocompletion. Error squiggles. All pointing at the same Lumos LSP backend.

Why This Matters

Developer experience is everything. The difference between "I'll try this tool" and "I'll stick with my current workflow" often comes down to: does my editor understand it?

Lumos files now light up with proper colors. Types autocomplete. Errors show inline before you compile. That friction reduction compounds over thousands of keystrokes.

The whole toolchain lives under the GitHub org. Each plugin is standalone — use whichever matches your editor. They all talk to the same LSP server, so the intelligence is consistent everywhere.

The Lesson

Build the foundation first (Tree-sitter), then the integrations become mechanical. Invest in LSP — write the intelligence once, distribute it everywhere. And never underestimate how much editor support affects adoption.

Editors Supported: VSCode, Neovim, IntelliJ/Rust Rover, Sublime Text, Emacs, + any Tree-sitter client

Stack: Tree-sitter, LSP, TypeScript, Lua, Kotlin, Emacs Lisp

Links: Tree-sitter Grammar • Neovim • VSCode • IntelliJ