The core is small and knows nothing about the GUI. Formats, highlighting, themes and tools attach to it through an API expressed in plain C. That single boring decision is what keeps an extension working across compilers and languages.
01 · why c abi
A C++ ABI is not stable between compilers, standard libraries or even build flags. An editor that exposed C++ classes to plugins would force every extension author to match its exact toolchain — and would break them on the next compiler upgrade.
The boundary is therefore described in C: opaque handles, plain structs and function pointers. A plugin built with MSVC loads into a build produced by Clang; a plugin written in C or Rust loads next to one written in C++.
The core stays GUI-free. A format plugin pulls in no interface dependencies, which is what makes the core testable and the editor's behaviour on large files predictable.
02 · plugin kinds
Teaches the editor a file type: how it is read, presented and written. csv (table mode) and epub (WYSIWYG) are of this kind.
Supplies a grammar and indentation rules. The bundled cpp plugin wires up a tree-sitter grammar.
Adds a capability over the open document or the project: ripgrep, git, clangd.
Ships a palette and appearance parameters within the existing design directions.
03 · shape
It identifies itself, declares the ABI version it was built against, and returns a table of callbacks for its kind.
/* schematic — see PluginAPI.h in the SDK for the authoritative names */ typedef struct the_plugin_desc { uint32_t abi_version; /* checked by the host on load */ const char* id; /* "csv", "markdown", ... */ const char* name; const char* version; uint32_t kind; /* format | highlight | tool | theme */ } the_plugin_desc; /* the only symbols the host looks for */ const the_plugin_desc* the_plugin_describe(void); int the_plugin_init(const the_host_api* host, the_plugin_ctx** out); void the_plugin_shutdown(the_plugin_ctx* ctx);
placeholder
The block above shows the shape of the boundary, not the real signatures. Exact type and function names must be lifted from core/include/editor/PluginAPI.h in the SDK before this page goes live — inventing an API in documentation is worse than leaving the section empty.
04 · build
The template depends on the public headers only and produces one shared library. The core is not rebuilt and is not linked into your plugin.
placeholder
Real target names, CMake options, the minimum toolchain versions and macOS signing requirements must be confirmed against the SDK.
# schematic sequence, exact targets from the SDK $ cmake -S . -B build \ -DTHE_SDK=/path/to/the-sdk $ cmake --build build --config Release # → build/the-plugin-example.(dll|dylib)
05 · install
placeholder
The plugin directory path per platform must be taken from the build.
06 · compatibility
| Guarantee | What it means for you |
|---|---|
| Compiler-independent | MSVC, Clang and GCC builds interoperate; no matching of standard-library flavours. |
| Language-independent | Anything able to export C symbols works: C, C++, Rust and others. |
| Versioned boundary | The plugin declares its ABI version and the host checks it, so an incompatible plugin fails loudly instead of crashing the editor. |
| No core rebuild | A plugin attaches to a released build of The. |
07 · not yet
A third-party plugin runs in the editor's process with its privileges. A WASM sandbox is planned, without a date.
No catalogue and no licensing for extensions — installation is manual.
The boundary may still change; such changes will be listed in the changelog.
Until a sandbox exists, only run plugins whose source you have read.