ecode: A Lua-Configured Editor Built on the eepp GUI

The problem ecode targets: editor startup and project indexing on modern hardware

The README states the editor is "designed for modern hardware with a focus on responsiveness and performance." That framing points to two costs that grow with repository size: application startup and project-wide search. ecode's stated philosophy is to "load as few files and resources as possible and load asynchronously as many resources as possible," with startup time described as critical. The project also assumes specific hardware: low file system latency (SSD), a high core count, and decent GPU acceleration. This is not an editor aimed at machines where the GPU is absent or where the disk is a spinning platter. The intended user is an engineer working in a repository large enough that indexing and searching are noticeable, on a workstation that can feed a hardware-accelerated GUI. The project's own framing is that terminals are part of the developer workflow, so the editor bundles a terminal rather than expecting you to switch windows.

How ecode uses .gitignore as the project index filter

Folders are treated as projects, and ecode reads the repository's .gitignore to decide what to index. Files listed there are excluded from project-wide searches and navigation. The README argues this produces "faster and more accurate search outcomes," which is a plausible consequence of not walking build output and dependency directories, though the repository does not publish measurements. Two override files live in the .ecode/ subfolder. .ecode/.prjallowed takes glob patterns for files that .gitignore ignores but you still want indexed. .ecode/.prjdisallowed takes glob patterns for files that .gitignore does not ignore but you want excluded. There is a third filter: by default ecode indexes only file types it officially supports, and unsupported files are excluded unless their patterns are added to .ecode/.prjallowed. That default is the part most likely to surprise people. If you work in a language or file type the editor does not recognize, the file will not appear in project search until you add a pattern, even if it is tracked in Git and not ignored. The design is coherent, but it means the editor's notion of "my project" depends on a list of supported extensions that the README does not enumerate.

Architecture: ecode is a client of the eepp GUI, and its source lives in that repository

ecode is built on the hardware-accelerated eepp GUI, and the README describes it as "the first serious project using the eepp GUI" and says it is being developed partly to improve that library. The practical consequence is unusual for an editor: the source code is not in the ecode repository. According to the README, the editor source is located in the eepp repository under src/tools/ecode. Anyone filing a bug against editor behaviour, or reading the implementation to understand a config key, has to work in a different repository than the one they downloaded. That coupling is a real cost. It also explains the Lua connection: the primary language listed for the repository is Lua, which is consistent with the plugin and configuration model rather than the GUI core. Features that run other processes are implemented as plugins: linter, formatter, LSP client, debugger, Git and spell checker. The README states that plugins and non-main functionality "should never lock the main thread (GUI thread) or at least should block it as little as possible," which is the architectural rule that keeps the UI responsive while a language server or linter runs.

Feature set: LSP, DAP, Git, terminal and a command palette in one window

The notable features list covers syntax highlighting for over 100 languages with nested highlighting and LSP semantic highlighting, multi-cursor editing, LSP support, debugger support via the Debug Adapter Protocol, Git integration, a terminal, a command palette, auto-completion, customizable linter and formatter support, customizable color schemes and key bindings, configurable build pipelines, global search and replace, an AI Assistant plugin with ACP support, a minimap, unlimited editor splitting, a file system tree view with real-time change detection, hot reload, per-project settings, code folding, soft wrap, snippets, session snapshot and periodic backup, and Perl regular expressions plus Lua pattern searches. That is a long list, and it puts ecode in the same functional bracket as editors that ship an integrated debugger and language server client. The claim worth noting is that language support is "easily extendable," which in practice means writing Lua rather than installing a package from a registry. The README does not describe a plugin registry, versioning scheme, or review process for third-party plugins. It says the author supervises "any new content that might affect the application quality and performance," which is a deliberate constraint on the ecosystem.

Getting ecode running: releases, the WASM demo and its documented limits

The repository lists three recent releases: ecode-0.8.1 from 2026-07-21, ecode-0.8.0 from 2026-04-26, and ecode-0.7.4 from 2026-01-11. The README does not include build-from-source instructions, package manager commands, or a list of prebuilt artifacts for each platform, so anyone wanting to compile it has to consult the eepp repository, since that is where the source lives. The one runnable path the README does give is the browser demo, hosted at cdn.ensoft.dev with the query parameter run=ecode.js. The demo has documented constraints that matter for evaluating the editor. It requires a modern browser with SharedArrayBuffer support. The linter, formatter, LSP client and debugger plugins will not work because they run other processes, with the exception of native formatters. The WebGL renderer is described as unoptimized, though the README says performance is still good in Chromium-based browsers. The demo targets desktop resolutions, and mobile is described as unusable because the IME keyboard will not appear due to an Emscripten limitation. If your evaluation depends on language server completion or debugging, the browser demo cannot show it to you.

Where ecode is the wrong tool

The filtering model is the first place things break down. Because indexing is limited to officially supported file types by default, a repository full of configuration formats, templates, or a niche language will show incomplete search results until someone maintains .ecode/.prjallowed. That file becomes another piece of project infrastructure that has to be kept in sync as the repository grows. The second constraint is the plugin model. There is no evidence in the README of a marketplace, a plugin versioning scheme, or a compatibility contract between ecode releases and third-party plugins. The author's stated policy of supervising new content limits the risk of a plugin degrading the editor, but it also limits how quickly the ecosystem can grow. The third constraint is hardware. The philosophy explicitly assumes SSD latency and GPU acceleration, and the GUI is hardware-accelerated throughout. On a remote workstation, a virtual desktop, or a machine with weak GPU drivers, the assumptions behind the design stop holding. Finally, the WASM build is explicitly not a development focus. The README says there are "plenty of good solutions out there" for the web and that there are no plans to focus on it, so the browser version should be treated as a demo, not a deployment target.

Alternatives and the difference in approach

The topics list on the repository points at the comparison set directly: lite, lite-xl, Geany, Lapce, Zed, Sublime Text and VS Code. The most instructive contrast is with lite and lite-xl, which share the Lua configuration model. Those editors are built around a small C core with Lua used for both configuration and plugins, and they are designed to run on modest hardware. ecode keeps the Lua extensibility but inverts the hardware assumption: it requires GPU acceleration and treats SSD latency and high core count as expected. That is a different bet. If you are on a thin laptop or a remote session, the lite family fits better. Lapce and Zed sit on the other side, closer to ecode in their emphasis on responsiveness and native rendering, but they are Rust-based with their own plugin systems, so the extension story differs. Geany is the older, GTK-based option with a mature ecosystem and a much lower hardware floor. VS Code is the default for teams that need broad extension coverage and remote development, at the cost of a heavier runtime. ecode's distinct position is the combination of a hardware-accelerated GUI, Lua configuration, and .gitignore-as-project-filter. That combination is the reason to pick it, and the reason it will not fit everyone.

Maintenance, licensing and what to check before adopting

ecode is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive, well-understood licence, though the usual caveat applies: the repository does not state which files fall under which terms, and the editor source lives in the eepp repository, so anyone redistributing a build should confirm the licence situation across both repositories. This is not legal advice. On maintenance, the release cadence visible in the supplied data is roughly one release every two to three months across 2026, with 0.7.4 in January, 0.8.0 in April, and 0.8.1 in July. The repository is not archived and was last pushed in September 2026. The upgrade cost that is specific to this project comes from the eepp coupling: because the editor is developed alongside the GUI library and its source sits in that repository, a GUI change and an editor change can arrive together. Anyone tracking a fork or pinning a version should read the eepp changelog alongside the ecode release notes. The concrete first step is to download the 0.8.1 release for your platform, open a repository with a non-trivial .gitignore, and check whether the files you expect to find in global search actually appear. If they do not, the fix is a pattern in .ecode/.prjallowed, and that is the file you will be maintaining.

Editorial conclusion

Adopt ecode if you want a hardware-accelerated editor with LSP, DAP and Git integration that reads your .gitignore as its project filter and is configured in Lua. Do not adopt it if you need a stable plugin marketplace, a large third-party extension ecosystem, or a browser-based workflow, since the README states the LSP, DAP and linter plugins cannot run in the WASM demo. Before committing, verify that your platform has a prebuilt release for 0.8.1, that your language server starts correctly under the ecode LSP client, and that the .ecode/.prjallowed and .ecode/.prjdisallowed files behave as described when your repository ignores generated or vendored directories.

Official sources

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