SpartanJ/ecode: a Lua-built code editor for editors who care about startup time

What ecode is, and the specific problem it targets

ecode is a lightweight multi-platform code editor developed with the hardware-accelerated eepp GUI. The README states that the project exists with a focus on responsiveness and performance, and that it is the first serious project using eepp, with the editor being developed partly to improve that GUI library. That framing matters: ecode is not only an editor, it is also the proving ground for its own UI toolkit.

The problem it targets is startup cost and resource use. The philosophy section says startup time is considered critical, that as few files and resources as possible should load, and that resources should load asynchronously where they can. It also states that the implementation prioritizes performance and memory usage over simplicity, and that modern hardware is assumed: low file system latency (SSD), a high core count, and decent GPU acceleration. That is an explicit trade-off. On an older machine with a spinning disk and weak integrated graphics, the design assumptions do not hold.

The intended user is a developer who wants an uncluttered GUI, syntax highlighting across more than 100 languages, and a terminal in the same window, without the footprint of a full IDE. The README lists LSP, Debug Adapter Protocol, Git integration, a command palette, multi-cursor editing, code folding, a minimap, and unlimited editor splitting among the notable features.

How ecode works: eepp, folders as projects, and .gitignore as configuration

The core architecture is a GUI layer plus plugins. ecode is built on the eepp GUI, which provides the rendering and widget layer, and the editor's functionality beyond the core is delivered through plugins. The README names linter, spell checker, LSP, DAP, Git and more as plugin categories, and states that plugins and non-main functionality should never lock the GUI thread, or should block it as little as possible. That constraint explains why language servers and debug adapters are run as separate processes rather than in-process: a language server that hangs does not freeze the window.

The project model is the most distinctive mechanism. In ecode, folders are treated as projects, similar to other editors, but the editor uses the repository's .gitignore file as project configuration. Files listed there are excluded when indexing project files, which keeps project-wide search and navigation limited to relevant files. Two override files live in a .ecode/ subfolder: .prjallowed adds glob patterns to include files that .gitignore ignores, and .prjdisallowed adds glob patterns to exclude files that .gitignore does not ignore. By default, only file types ecode officially supports are indexed; unsupported files are excluded unless their patterns are added to .ecode/.prjallowed.

That is a real design decision with consequences. If your repository's .gitignore is inaccurate, ecode's search results inherit that inaccuracy. If you work in a language ecode does not list as supported, you will need a .prjallowed entry before the file appears in project-wide search. The README does not describe what happens when a pattern in .prjallowed conflicts with one in .prjdisallowed, so precedence between the two files is undocumented.

Installing ecode: it lives inside the eepp repository

There is no install section in the README and no published package or installer is referenced. The README states that the source code is located at the eepp project repository, with the ecode editor source at src/tools/ecode on the develop branch. The practical first step is therefore to clone eepp and build it, which produces ecode as one of its tools. The README does not document the build commands, so check the eepp repository's own build instructions for your platform before starting.

Once built, the first real use is opening a folder as a project. The README describes folders as projects and says project and folder state persists between sessions, so the editor reopens what you had. A typical first session is to point the editor at a repository you already track with Git, since ecode reads that repository's .gitignore to decide what to index. Open the folder in ecode and project-wide search should skip the paths listed in .gitignore.

To bring an ignored file back into the index, the README says to add glob patterns to .ecode/.prjallowed:

mkdir -p .ecode
printf 'build/generated/**\n' >> .ecode/.prjallowed

After that, project-wide search should include files matching that pattern. To exclude a file that .gitignore does not cover, add its glob to .ecode/.prjdisallowed instead. The README does not document a command-line flag for opening a folder, so use the GUI's folder or project entry point.

Where ecode breaks down, and what the README leaves unsaid

The clearest limitation is the web build. ecode can be compiled to WASM and run in a browser, but the README is explicit that the linter, formatter, LSP client and debugger plugins will not work there, because they operate by running other processes. Native formatters are the exception. The demo also requires a browser with SharedArrayBuffer support, is designed for desktop resolutions, and the README says mobile is unusable because the IME keyboard will not show up due to an emscripten limitation. If your workflow depends on language intelligence, the web version is a viewer, not a working editor.

The second limitation is hardware. The philosophy section expects an SSD, a high core count and decent GPU acceleration. That is a narrower band than most editors assume. A machine that runs a terminal-based editor comfortably may not be the machine ecode was designed for.

The third is ecosystem. The README says new features and plugins are accepted, but the author supervises anything that might affect application quality and performance. That is a deliberate gate. It keeps the editor consistent, and it also means the plugin surface will not grow the way an open marketplace does. The README does not document a plugin registry, a versioning scheme for plugins, or a rollback path if an update breaks a language server configuration.

ecode compared with Zed and Lite XL

The repository's own topics list zed, lite-xl, lapce, geany, sublime-text and vscode, which places ecode in the lightweight-editor category rather than the full-IDE category. The most useful comparison is with Zed, because a search query for "ecode vs zed" exists and because both projects are built around responsiveness.

The difference is in the stack and the distribution. ecode is written in Lua and built on the eepp GUI, a C++ GUI library from the same author, and it is distributed as source inside the eepp repository at src/tools/ecode. Zed is not described anywhere in the ecode README, so the honest comparison stops at what ecode's own architecture implies: adopting ecode means adopting eepp as a build dependency, and the editor's development is tied to improving that GUI library. That coupling is a benefit if you want a small, coherent stack, and a cost if you wanted an editor you could build without a GUI toolkit's own build system.

Against Lite XL, the difference is scope rather than philosophy. Both are lightweight and Lua-based. ecode ships LSP, DAP, Git integration, a terminal, a command palette and an AI assistant plugin with ACP support as first-class features, while the README frames the project as a full editor with plugins rather than a minimal core. The trade-off is that more built-in surface means more configuration to learn, and ecode's .gitignore-driven project model is one more thing to understand before search behaves as expected.

Licence, maintenance and the cost of upgrading

ecode is MIT licensed, and the LICENSE file sits at the top level of the repository. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are preserved. Because ecode is distributed inside the eepp repository, check the licence of eepp itself as well before redistributing a build, since the editor source lives in that tree. This is a description of the licence text, not legal advice.

On maintenance, the most recent release listed is ecode 0.8.1 on 2026-07-21, following 0.8.0 on 2026-04-26 and 0.7.4 on 2026-01-11. The last push to the repository was on 2026-09-06, and the repository is not archived. Release cadence over the listed versions is roughly one minor release per quarter, with patch releases in between, which is a reasonable pace for a project of this size.

The upgrade cost is specific to the distribution model. Because ecode is built from the eepp tree, updating ecode generally means updating eepp, and eepp is also the GUI library the editor is designed to improve. A change in the GUI layer can therefore change editor behaviour. The README does not document a rollback procedure, a supported-versions policy, or how per-project settings survive an upgrade. If you run ecode across a team, pin the eepp commit you build from rather than tracking the develop branch.

Editorial conclusion

ecode fits developers who want a small, hardware-accelerated editor with LSP, DAP, Git and terminal support, and who are comfortable building from source inside the eepp repository. It is the wrong choice if you need a packaged installer, a web-first workflow, or a plugin ecosystem with the breadth of VS Code. Before adopting it, verify that your toolchain can build eepp on your platform, then confirm that your language server and debug adapter launch correctly from the editor, because the README does not document a fallback path when those external processes fail.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SpartanJ/ecode on GitHub