Skip to content
Oeiuwq Faith Blog OpenSource Porfolio

SpartanJ/ecode

Lightweight multi-platform code editor designed for modern hardware with a focus on responsiveness and performance.

SpartanJ/ecode.json
{
"createdAt": "2022-06-08T02:19:57Z",
"defaultBranch": "main",
"description": "Lightweight multi-platform code editor designed for modern hardware with a focus on responsiveness and performance.",
"fullName": "SpartanJ/ecode",
"homepage": "",
"language": "Lua",
"name": "ecode",
"pushedAt": "2025-10-17T03:43:21Z",
"stargazersCount": 1479,
"topics": [
"code",
"code-editor",
"debugger",
"developer-tools",
"editor",
"geany",
"gui",
"ide",
"lapce",
"lite",
"lite-xl",
"lsp-client",
"sublime-text",
"terminal",
"text",
"text-editor",
"vscode",
"zed"
],
"updatedAt": "2026-01-07T23:47:10Z",
"url": "https://github.com/SpartanJ/ecode"
}


ecode

ecode is a lightweight multi-platform code editor designed for modern hardware with a focus on responsiveness and performance. It has been developed with the hardware-accelerated eepp GUI, which provides the core technology for the editor. The project comes as the first serious project using the eepp GUI, and it’s currently being developed to improve the eepp GUI library as part of one of its main objectives.

ecode - Code Editor

For more screenshots checkout running on macOS, running on Windows, running on Haiku, low dpi, code completion, terminal, file locator, file formats, global find, global replace, linter.

  • Lightweight
  • Portable
  • Uncluttered GUI
  • Syntax Highlighting (including nested syntax highlighting, supporting over 100 languages and LSP semantic highlighting)
  • Multi-cursor support
  • LSP support
  • Debugger support via Debug Adapter Protocol
  • Git integration
  • Terminal support
  • Command Palette
  • Auto-Completion
  • Customizable Linter support
  • Customizable Formatter support
  • Customizable Color-Schemes
  • Customizable keyboard bindings
  • Configurable build pipelines
  • Fast global search (and replace)
  • AI Assistant plugin
  • Minimap
  • Unlimited editor splitting
  • Easily extendable language support
  • Customizable and scalable (non-integer) GUI (thanks to eepp GUI)
  • Dark & Light Mode
  • File system Tree View (with real-time file system changes)
  • Smart hot-reload of files
  • Folders as Projects with .gitignore support *
  • Per Project Settings
  • Smart and fast project file locator
  • Multiline search and replace
  • Project/Folder state persist between sessions
  • Soft-wrap
  • Code-folding
  • Session Snapshot & Periodic Backup
  • Perl Regular Expressions and Lua pattern searches support
  • Plugins support (linter, spell checker, LSP, DAP, Git, and more).

In ecode, folders are treated as projects, similar to other code editors. However, ecode distinguishes itself by using the repository’s .gitignore file as a project configuration to streamline file management.

ecode automatically excludes files listed in the .gitignore file when indexing project files. This ensures that only relevant files are considered for project-wide searches and navigation, resulting in faster and more accurate search outcomes.

To override .gitignore filtering, ecode supports two configuration files in the .ecode/ subfolder:

  • .prjallowed: Add glob patterns to include files ignored by .gitignore, making them available for indexing and searching.
  • .prjdisallowed: Add glob patterns to exclude files that are not ignored by .gitignore, providing precise control over file visibility.

By default, ecode indexes only file types it officially supports. Unsupported files are excluded unless their patterns are explicitly added to the .ecode/.prjallowed file.

This approach ensures an efficient and tailored project management experience with flexible customization options.

Some points to illustrate the project philosophy:

  • Extendable functionality but in a controlled environment. New features and new plugins are accepted, but the author will supervise any new content that might affect the application quality and performance.
  • Load as few files and resources as possible and load asynchronously as many resources as possible. 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: expected hardware should have low file system latency (SSD), high cores count and decent GPU acceleration.
  • Plugins and non-main functionality should never lock the main thread (GUI thread) or at least should block it as little as possible.
  • Terminals are part of the developer workflow.

ecode can be compiled to WASM and run in any modern browser. There are no plans to focus the development on the web version (at least for the moment) since there are plenty of good solutions out there. But you can give it a try:

Demo here

  • You’ll need a modern browser with SharedArrayBuffer support
  • Linter, Formatter, LSP Client and Debugger plugins won’t work since they work by running other processes (except for the native formatters that are available)
  • WebGL renderer isn’t optimized, so it’s not as fast as it could/should be (still, performance is good in chromium based browsers)
  • Demo is designed for desktop resolutions (mobile is unusable, IME keyboard won’t show up due to an emscripten limitation)

Currently, the source code is located at the eepp project repository. ecode editor source is located at src/tools/ecode. ecode is being used to actively improve and iterate the eepp GUI library. At some point, it will be migrated to this repository. The ecode repository should be used for issues and documentation. PRs for ecode will be accepted at the eepp repository.

There are scripts for each supported platform ready to build the application. For Linux and macOS it is trivial to build the project, you’ll just need to have GCC/Clang installed and also the development library from libSDL2. Windows build script is currently a cross-compiling script and it uses mingw64. But it also can be easily built with Visual Studio and libSDL2 development libraries installed. For more information on how to build manually a project please follow the eepp build instructions. The project name is always ecode (so if you are building with make, you’ll need to run make ecode).

  • Linux build script can be found here. Running build.app.sh will try to build the AppImage package and tar.gz with the compressed application. ecode folder will contain the uncompressed application.
  • macOS build script can be found here. Running build.app.sh will create ecode.app. Run create.dmg.sh to create the dmg file. ecode.app folder will contain the uncompressed application.
  • Windows cross-compiling build script can be found here. Running build.app.sh will create a zip file with the zipped application package. ecode folder will contain the uncompressed application. To build from Windows follow the instructions here.
  • FreeBSD build script can be found here. Running build.app.sh will try to build a tar.gz with the compressed application. ecode.app folder will contain the uncompressed application.
  • Haiku build script can be found here. Running build.app.sh will try to build a tar.gz with the compressed application. ecode.app folder will contain the uncompressed application.

Nightly builds are being distributed here for the more impatient users. ecode is being developed actively, nightly builds may not be stable for daily usage unless there’s a pending unreleased fix required for the user.

Plugins extend the base code editor functionality. Currently all plugins are enabled by default, but they are optional and they can be disabled at any time. ecode implements an internal protocol that allow plugins to communicate with each other. The LSP protocol is going to be used as a base to implement the plugin communication. And, for example, the Linter plugin will consume the LSP to improve its diagnostics. Also the Auto Complete module will request assistance from the LSP, if available, to improve the completions and to provide signature help.

Linter support is provided by executing already stablished linters from each language. ecode provides support for several languages by default and can be extended easily by expanding the linters.json configuration.

For more information [read the linter documentation]!(docs/linter.md).

LSP support is provided by executing already stablished LSP from each language. ecode provides support for several languages by default and can be extended easily by expanding the lspclient.json configuration.

For more information [read the lsp client documentation]!(docs/lsp.md).

Debugger support is provided by the implementation the Debug Adapter Protocol. ecode is able to debug any language implementing this protocol, although the protocol is generic sometimes requires to support some of the languages some specific adaptation is needed, so initially the support is limited to the languages mentoined in the support list.

For more information on how to use the debugger [read the debugger documentation]!(docs/debugger.md).

ecode provides some basic Git integration (more features will come in the future). Its main purpose is to help the user to do the most basics operations with Git. Some of the current features supported: git status and stats visualization (files states), commit, push, checkout, pull, fetch, fast-forward merge, creating+renaming+deleting branches, managing stashes. All stats will be automatically updated/refreshed in real time. There’s also some basic configuration available.

For more information [read the git integration documentation]!(docs/git.md).

The formatter plugin works exactly like the linter plugin, but it will execute tools that auto-format code. ecode provides support for several languages by default with can be extended easily by expanding the formatters.json configuration.

For more information [read the formatter documentation]!(docs/formatter.md).

The auto-complete plugin is in charge of providing suggestions for code-completion and signature help.

For more information [read the auto-complete documentation]!(docs/autocomplete.md).

The AI Assistant is a simple but effective LLM Chat UI. You’ll be able to chat with different models from within the editor.

For more information [read the AI assistant documentation]!(docs/aiassistant.md).

The spell checker plugin uses the typos specialized tool for code spell checking.

For more information [read the Spell Checker documentation]!(docs/spellchecker.md).

The XML Tools plugin (disabled by default) provides some nice to have improvements when editing XML content.

For more information [read the xml tools documentation]!(docs/xmltools.md).

ecode respects the standard configuration paths on each OS:

  • Linux: uses XDG_CONFIG_HOME, usually translates to ~/.config/ecode/plugins
  • macOS: uses Application Support folder in HOME, usually translates to ~/Library/Application Support/ecode/plugins
  • Windows: uses APPDATA, usually translates to C:\Users\{username}\AppData\Roaming\ecode\plugins

All plugin configurations are designed to be overwritable by the user. This means that the default configuration can be replaced with custom configurations from the user. For example, if the user wants to use a different linter, it just needs to declare a new linter definition in its own linter configuration file. The same applies to formatters and LSPs servers. Plugins will always implement a “config” for plugins customization, and will always implement a “keybindings” key to configure custom keybindings.

ecode is highly customizable and extendable thanks to its several configuration files. If you’re interested in creating new color schemes for the editor or terminal, or in creating new UI themes please check our documentation:

For more information [read the UI Customization documentation]!(docs/uicustomizations.md).

ecode is constantly adding more languages support and also supports extending it’s language support via configuration files (for every feature: syntax highlighting, LSP, linter and formatter).

LanguageHighlightLSPLinterFormatterDebugger
.htaccessNoneNoneNoneNone
.ignore fileNoneNoneNoneNone
[x]it!NoneNoneNoneNone
adaada_language_serverNoneNoneNone
adeptAdeptLSPNoneNoneNone
angelscriptNoneNoneNoneNone
arm assemblyNoneNoneNoneNone
awk scriptNoneNoneNoneNone
batNoneNoneNoneNone
bazelNoneNoneNoneNone
bendNoneNoneNoneNone
bladeNoneNoneNoneNone
blueprintNoneNoneNoneNone
boltNoneNoneNoneNone
brainfuckNoneNoneNoneNone
buzzNoneNoneNoneNone
cclangdcppcheckclang-formatgdb / lldb-dap
c2NoneNoneNoneNone
c3c3-lspNoneNoneNone
carbonNoneNoneNoneNone
clojureclojure-lspNoneNoneNone
cmakecmake-language-serverNoneNoneNone
cmakecacheNoneNoneNoneNone
covscriptNoneNoneNoneNone
cppclangdcppcheckclang-formatgdb / lldb-dap
crystalcrystallineNoneNoneNone
csharpOmniSharpNoneNoneNone
cssemmet-language-serverNone[native]!(#native)None
csvNoneNoneNoneNone
curryNoneNoneNoneNone
dserve-dNoneNonegdb
dartdart language-serverNoneNonedart
diffNoneNoneNoneNone
dockerfiledocker-langserverNoneNoneNone
ecNoneNoneNoneNone
elenaNoneNoneNoneNone
elixirelixir-lsNoneNoneNone
elmelm-language-serverNoneNoneNone
environment fileNoneNoneNoneNone
fantomNoneNoneNoneNone
fennelNoneNoneNoneNone
fixscriptNoneNoneNoneNone
flow9NoneNoneNoneNone
fortranfortlsNoneNonegdb
fstabNoneNoneNoneNone
gdscriptNoneNoneNoneNone
gleamNoneNoneNoneNone
glslglsl_analyzerNoneNoneNone
gnNoneNoneNoneNone
gnuplotNoneNoneNoneNone
gogoplsNonegoplsgdb / delve
graphqlNoneNoneNoneNone
groovyNoneNoneNoneNone
hareNoneNoneNoneNone
haskellhaskell-language-serverhlintormoluNone
haxeNoneNoneNoneNone
hlslNoneNoneNoneNone
htmlemmet-language-serverNoneprettierNone
idlNoneNoneNoneNone
iniNoneNoneNoneNone
ispcNoneNoneNoneNone
jaiNoneNoneNoneNone
janetNoneNoneNoneNone
javajdtlsNoneclang-formatNone
javascripttypescript-language-serveroxlintprettiernode
javascriptreacttypescript-language-serverNoneNoneNone
jsonNonejq[native]!(#native)None
juleNoneNoneNoneNone
juliaLanguageServer.jlNoneNoneNone
kokaNoneNoneNoneNone
kotlinkotlin-language-serverktlintktlintNone
l.b. stanzaNoneNoneNoneNone
latextexlabNoneNoneNone
lispNoneNonerosNone
lobsterNoneNoneNoneNone
lualua-language-serverluacheckNoneNone
m4NoneNoneNoneNone
makefileNoneNoneNoneNone
markdownmarksmanNoneNoneNone
mesonNoneNoneNoneNone
modula2NoneNoneNoneNone
modula3NoneNoneNoneNone
moonscriptNoneNoneNoneNone
msbuild solutionNoneNoneNoneNone
neluaNoneneluaNoneNone
nimnimlspnimNoneNone
nixNoneNoneNoneNone
objeckNoneNoneNoneNone
objective-cclangdNoneclang-formatNone
objective-cppclangdNoneclang-formatNone
ocamlOCaml-LSPNoneNoneNone
odinolsNoneNonelldb-dap
openscadNoneNoneNoneNone
pascalNoneNoneNonegdb
perlPerlNavigatorNoneNoneperl-ls
phpphpactorphpNoneNone
pico-8NoneNoneNoneNone
pkg-configNoneNoneNoneNone
plaintextNoneNoneNoneNone
poNoneNoneNoneNone
ponyNoneNoneNoneNone
postgresqlNoneNoneNoneNone
powershellNoneNoneNoneNone
pythonpylspruffruffdebugpy
qbsNoneNoneNoneNone
qmakeNoneNoneNoneNone
rr languageserverNoneNoneNone
racketracket-langserverNoneNoneNone
raveNoneNoneNoneNone
rc scriptNoneNoneNoneNone
rescriptNoneNoneNoneNone
ringNoneNoneNoneNone
rpm specNoneNoneNoneNone
rubysolargraphNoneNoneNone
rustrust-analyzerNonerustfmtgdb / lldb-dap
sassemmet-language-serverNoneNoneNone
scalametalsNoneNoneNone
schemeNoneNoneNoneNone
shellscriptbash-language-serverNoneNoneNone
smallbasicNoneNoneNoneNone
soliditysolcsolhintNoneNone
sqlNoneNoneNoneNone
squirrelNoneNoneNoneNone
svelteNoneNoneNoneNone
swiftsourcekit-lspNoneNoneNone
tclNoneNoneNoneNone
tealNonetlNoneNone
tomlNoneNoneNoneNone
tsvNoneNoneNoneNone
typescripttypescript-language-serveroxlintprettiernode
typescriptreacttypescript-language-serverNoneNoneNone
typstTinymistNoneNoneNone
vv-analyzerNonevNone
v1NoneNoneNoneNone
valavala-language-serverNoneNoneNone
verilogNoneNoneNoneNone
visual basicNoneNoneNoneNone
vuevlsNoneNoneNone
wrenNoneNoneNoneNone
x86 assemblyNoneNoneNoneNone
xmlemmet-language-server[native]!(#native)[native]!(#native)None
xtendNoneNoneNoneNone
yamlyaml-language-serverNoneNoneNone
yuescriptNoneNoneNoneNone
zephirNoneNoneNoneNone
zigzlszigziglldb-dap
üÜ language serverNoneNonegdb / lldb-dap

Native tag means that the feature is supported natively by ecode and it doesn’t need any external tool to function.

ecode brings a tool to display the current language support health. From ecode you can check its health status from Settings -> Tools -> Check Language Health, and from CLI you can use the --health flag: ecode --health. Use the health check flag to troubleshoot missing language servers, linters and formatters.

Check the health of all languages with ecode --health or ask for details about a specific language with ecode --health-lang=<lang>.

Users can add support for new languages with a very simple JSON file format.

For more information [read the custom languages documentation]!(docs/customlanguages.md).

Listed in no particular order:

  • General polishing
  • Improved plugin system (visual configuration, more flexibility/features)
  • AI assistant plugin
  • Snippets support
  • Macros support
  • Better integration with OSes
  • Modal editing
  • Maybe Remote development support
  • Maybe Tree-sitter support

The author is more than open to collaborations. Any person interested in the project is invited to participate. Many features are still pending, and the project will grow much more over time. Please, collaborate. =)

Why some characters are not being rendered correctly inside the editor?

Section titled “Why some characters are not being rendered correctly inside the editor?”

Some Unicode characters won’t be rendered in the editor out of the box. You’ll need to change the default monospace font in favor of a font that supports the characters you want to see that are not being rendered. You could also change the default fallback font in the case you want to use a traditional monospaced font. The default fallback font should cover a wide range of languages but you could need some special font (currently covers CJK languages).

  • No font sub-pixel hinting *1 *2
  • No VIM-mode / modal editing *3
  • No text-shaping support. *1 *4
  • No ligatures support (requires text-shaping) *1
  • No BiDi support (requires text-shaping) *1

*1 Current eepp feature limitations.

*2 I’m not a fan of sub-pixel hinting. But I’m more than willing to implement it, I’m not very versed in the matter, so any help will be appreciated.

*3 I’m not a VIM user, and I’m not qualified to implement the VIM mode or any modal editing. PRs are welcome to support this.

*4 Some work has been done to support text-shaping but it’s not ready for general usage. So it’s a work in progress.

This editor has a deeply rooted inspiration from the lite, lite-xl, QtCreator and Sublime Text editors. Several features were developed based on the lite/lite-xl implementations. Some features can be ported directly from lite: color-schemes and syntax-highlighting patterns (eepp implementation expands original lite implementation to add many more features).

ecode is being used mostly in Linux and macOS, it’s not well tested in Windows. If you find any issues with the editor please report it here.

This is a work in progress, stability is not guaranteed. Please don’t use it for critical tasks. I’m using the editor daily and is stable enough for me, but use it at your own risk.

MIT License