Volt Docs Editor architecture and runtime
Open Diagram User Packages Configuration Add a Language Changelog Get Started

Rust-powered modal editor platform

Volt is a modal editor with a layered, programmable core.

Volt combines a central runtime, compiled user packages, language tooling, and an SDL shell into one cohesive editing environment. The architecture is intentionally modular so the editor can grow without losing its shape.

Explore the system View full diagram
18 editor crates
YAML runtime plugin config
3 primary launch paths

Editor identity

Modal muscle with modern editor systems.

Volt aims to bridge fast modal editing with the capabilities people expect from a modern IDE: workspace discovery, external tooling, rich overlays, and programmable runtime services.

Customization model

User packages shape the experience.

Themes, language registrations, hook declarations, keybindings, and package metadata live in the compiled user layer so behavior stays declarative where possible instead of being scattered across the core.

Selected plugin settings also load from user/config.yaml at runtime — workspace roots, ACP clients, terminal defaults, and oil chords can change without a rebuild.

User packages guide →  ·  Configuration guide →

Workspace shape

Small crates, clear boundaries.

The workspace is split by domain: text buffers, rendering, themes, syntax, terminal execution, Git, language servers, debugging, plugins, and the SDL shell all have explicit homes.

Documentation hub

Pick the guide that matches your task.

Filter guides, hooks, and config keys.

Plugins

User Packages

Create plugins, wire hooks and commands, edit builtins, and understand the compiled user library ABI.

 Runtime YAML

Configuration

Edit user/config.yaml and child files for workspace discovery, ACP, UI defaults, and oil without recompiling.

 Languages

Adding a Language

Register tree-sitter grammars, theme mappings, hook bindings, and optional LSP servers for a new language.

 Architecture

System Diagram

Explore the full runtime topology from the SDL shell through the plugin host to buffers, syntax, and tooling crates.

 History

Changelog

Track new packages, rendering changes, language additions, and documentation updates across releases.
Customize

Three customization layers

Rust modules in user/*.rs for commands and hooks. YAML config for runtime plugin data. TOML themes for colors and shared editor options.

Architecture

The system map that drives everything else.

Open the full architecture diagram
01

Thin executable, rich bootstrap.

`crates\volt` stays intentionally lean while the bootstrap flow assembles the runtime, user packages, registries, and shell entry points.

02

EditorRuntime is the gravity well.

The runtime binds model state, services, commands, hooks, and keymaps into one programmable center of the editor.

03

User packages shape the experience.

Themes, keybindings, language tools, hooks, and package metadata live in the compiled `user` layer rather than being hard-wired into the core.

System layers

How the runtime is partitioned.

Shell

Editor shell and UI state

`editor-sdl` owns the SDL shell, shell-local services, picker overlays, hover flows, popup handling, and workspace interactions.

Plugins

Package metadata to behavior

`user/sdk` defines the ABI-stable plugin surface and is the only stable ABI crate, while `editor-plugin-host` turns package declarations into commands, hooks, and keybindings.

Core

Model, commands, hooks, keymaps

`editor-core` centers the runtime while neighboring crates handle text buffers, syntax, themes, rendering, workspace discovery, search, and external tools.

Platform

Async systems and integration

Tokio-powered jobs, terminal execution, language tooling, debugging, and SDL platform work give Volt its editor-plus-IDE feel.

Workspace crates

The pieces that make up Volt.

The workspace is organized by domain so each subsystem stays legible and can evolve independently.

Application entry

  • volt executable
  • editor-sdl shell frontend
  • user compiled customization layer
  • xtask workflow automation

Core model

  • editor-core
  • editor-buffer
  • editor-render
  • editor-theme
  • editor-syntax
  • editor-icons

Workspace services

  • editor-fs
  • editor-picker
  • editor-jobs
  • editor-terminal
  • editor-git
  • editor-db
  • editor-path

Language tooling

  • editor-lsp
  • editor-dap
  • user/sdk
  • editor-plugin-host

Operator workflows

Common ways to understand and validate the editor.

01

Boot the hidden shell smoke test

Use the single-frame shell path to confirm the runtime launches cleanly without staying interactive.

02

Exercise the bootstrap path

The non-UI bootstrap demo is the clearest snapshot of runtime registration for commands, hooks, themes, syntax, and external tooling.

03

Validate the workspace pipeline

`cargo xtask ci` matches the CI-quality path when you need the full formatting, lint, and test sweep across the workspace.

Commands

High-signal entry points.

Launch the editor shell

cargo run -p volt

Starts the SDL shell demo and lets you explore the interactive editor surface.

Run the hidden smoke test

cargo run -p volt -- --shell-hidden

Useful for runtime verification when you want a non-interactive shell boot.

Inspect the bootstrap flow

cargo run -p volt -- --bootstrap-demo

Prints the subsystem summary for the clearest non-UI runtime overview.

Run the full validation path

cargo xtask ci

Executes the CI-grade format, lint, and test pipeline used across the workspace.