ecode: the editor repository holds no editor source, and its web demo drops every plugin

The repository named after the editor contains no editor source

The top level of this repository is .github/, CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE, README.md, docs/ and tools/. There is no src directory, no build manifest for the editor and no library code. The page is explicit about where the program lives: the source is in the eepp project repository, at src/tools/ecode, and the link points at that path on the `develop` branch. This repository is for issues and documentation, and the sentence that follows sets the split in full: pull requests for ecode are accepted at the eepp repository. The migration is stated as a future intention rather than a schedule, with the note that at some point the source will move here. Two smaller facts go with it. The repository records its primary language as Lua, which fits a tree carrying documentation and tools rather than a C++ editor. And it has no homepage set at all, so a reader who lands on it has the README, the docs folder and nothing else to go on.

The develop branch is what you would build, and no release is cut from it

Follow the source link and you arrive at eepp on its `develop` branch, while the releases for the editor are tagged in this repository: ecode-0.8.1 published 2026-07-21, ecode-0.8.0 on 2026-04-26 and ecode-0.7.4 on 2026-01-11. The last commit here is dated 2026-09-28, roughly ten weeks after the newest tag. So the branch a contributor is told to clone, the branch the project describes as under active iteration for its GUI library, and the version anyone installs from a release are three different points on a line, and nothing in the documentation states how far apart they are. The release notes are named after the version alone, ecode 0.8.1 and nothing more, so the tag itself carries no statement of what changed. If you are evaluating the editor, the choice is between a binary whose contents you can read from its tag name and a build from a moving branch, and the project does not offer a mapping between them.

The editor is also the test bed for its own GUI library

The opening paragraph does not describe ecode as a finished editor so much as a working application for a library. It has been developed with the hardware accelerated eepp GUI, which provides the core technology, and ecode is presented as the first serious project using that GUI. It goes further and names library work as one of the main objectives of the editor itself: ecode is being developed to improve and iterate the eepp GUI library. That framing has consequences for how you read a feature request or a regression. A change can be refused or reshaped on the grounds that it belongs in the GUI library rather than the editor, and an editor feature can appear because the library needed the capability exercised somewhere real. The same page states the rule directly for outside contributions: new features and new plugins are accepted, but the author supervises any new content that might affect application quality and performance. Extension is welcome and controlled by one person, and the reasoning behind the control is the library.

.gitignore is the project configuration, and unsupported files never appear

Folders are treated as projects, and the project configuration is the repository's own `.gitignore`. Files listed there are excluded automatically when project files are indexed, which the page presents as the reason project-wide search and navigation see fewer irrelevant entries. Two files in an `.ecode/` subfolder override it in either direction: `.prjallowed` takes glob patterns for files that `.gitignore` would exclude and makes them available again, while `.prjdisallowed` excludes files that `.gitignore` would let through. The rule that will surprise you comes next. By default ecode indexes only file types it officially supports, and anything unsupported is excluded unless its pattern is explicitly added to `.ecode/.prjallowed`. So a file can be visible to your shell, tracked by Git, present in the tree view and still be absent from the project file locator, from global search and from indexing, purely because its type is not on the supported list. Symmetric syntax highlighting is claimed for over 100 languages, but that is highlighting, not indexing. Adding one glob line is what brings an unusual file type back.

The browser build drops every plugin that needs another process

ecode compiles to WASM and runs in a modern browser, and the page is candid about what that costs. You need a browser with SharedArrayBuffer support. Linter, formatter, LSP client and debugger plugins will not work, because each of them works by running other processes, and the only exception named is the native formatters. The WebGL renderer is not optimized, so it is slower than it should be, though performance is described as good in Chromium based browsers. The demo targets desktop resolutions: on mobile it is unusable, and the IME keyboard will not show up because of an emscripten limitation. Set against that list of missing pieces, the page also says there are no plans to focus development on the web version, at least for the moment, since there are plenty of good solutions out there. Read together, those are the terms of a demonstration rather than a second product: the process-dependent half of the feature set is absent, and the project is not trying to fix it.

Lightweight is claimed in the feature list and measured nowhere

The first two entries in the feature list are Lightweight and Portable, followed by Uncluttered GUI. No figure appears anywhere behind them: no binary size, no resident memory, no startup time, no count of how many files are loaded at launch. The philosophy section is where the intent is stated instead, and it is specific about method rather than outcome. Load as few files and resources as possible, and load asynchronously as many as possible, because startup time of the application is considered critical. Use the machine resources but not abuse them. The editor implementation will try to prioritize performance and memory usage over simplicity. Developed with modern hardware in mind, where expected hardware should have low file system latency on an SSD, a high core count and decent GPU acceleration. That last line is a floor rather than a promise, and it is the closest the page comes to a requirement you could fail. The same philosophy says plugins and non-main functionality should never lock the main thread, or at least block it as little as possible.

The build from source instructions stop in the middle of a sentence

The last heading on the page is Build from Source, and it opens with the words There are scripts f before the text ends. No script name, no command and no toolchain requirement survives to be read there, which leaves the only route to a self-built binary undocumented on this page. What the tree does offer is a tools/ directory at the root, alongside the docs/ folder, so whatever those scripts are, they are in the repository even if the instructions describing them are not complete. The screenshots section has the same shape: twelve image links, captioned in prose as running on macOS, running on Windows, running on Haiku, plus low dpi, code completion, terminal, file locator, file formats, global find, global replace and linter. The Haiku and low dpi entries point at the scaling and platform work rather than the editing features. None of the images carries alt text, and several are hosted on a user-images path while the macOS one is an asset upload.

Thirty-six feature bullets and one rule about who reviews them

The feature list runs to thirty-six entries, from syntax highlighting with nested support and LSP semantic highlighting through multi-cursor, a debugger reached over the Debug Adapter Protocol, Git integration, a terminal, a command palette, configurable linter, formatter, color schemes and keyboard bindings, build pipelines, global search and replace, a minimap, unlimited editor splitting, dark and light mode, soft-wrap, code-folding, session snapshot and periodic backup, Perl regular expressions alongside Lua pattern searches, and snippets. Two of them are worth pulling out. An AI Assistant plugin with ACP support is listed as part of the editor rather than as an add-on, and unlimited editor splitting is an unusual thing to claim for an editor whose stated priority is low memory usage. Against all of that, the extension policy is one sentence: extendable functionality but in a controlled environment, where the author supervises any new content that might affect quality and performance. Feature breadth and a single gatekeeper are both facts about this project, and they pull against each other.

Editorial conclusion

ecode suits someone who wants a small editor with real LSP, debugger, Git and project state, and who is willing to follow the source into a second repository on a develop branch to build it. It suits less well anyone who expects the repository they cloned to contain the editor, or who needs the linter, the LSP client or the debugger in the browser build, since all three run other processes and none of them survive compilation to WASM. Before adopting it, clone the eepp repository rather than this one, check the release you are pinning against the develop branch you would build from, and read your project through the .gitignore rules before concluding a file is missing, because a file type the project does not support is invisible to search until a glob is added to .ecode/.prjallowed.

Frequently asked questions

Official sources

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