Skip to content

Releases

Changelog

0.1.0 -- Initial Public Release

Language & Runtime

  • F#-inspired functional syntax: let bindings, lambdas, pattern matching, pipe operators
  • Hindley-Milner type inference (Algorithm W) with optional annotations
  • Algebraic data types: records, discriminated unions, tuples
  • Result/Option types with ? propagation and try-with/try-finally
  • Lazy evaluation: lazy expr, force, seq { yield ... } sequences
  • Module system with import/open, standard library, user modules
  • Ref cells (ref, .value, <-) with GC write barrier
  • Indirect function calls, partial application, closures, mutual recursion
  • Mark-and-sweep garbage collector with slab-allocated object pool

Shell

  • Bash-compatible command execution: pipes, redirects, job control, globbing
  • 60+ inline builtins: file ops, text processing, networking, process management
  • Structured output: ls, ps, jobs return typed records
  • Output recognition files (.endo-output.yml) for external command output
  • Scoped resource management (let use) with auto-dispose
  • history (list, search, clear) and source builtins
  • tail -f follow mode for files and stdin

Interactive UX

  • Multiline editor with undo/redo, clipboard (OSC 52), mouse support
  • Fish-style ghost text suggestions from persistent history
  • Context-aware tab completion (commands, files, variables, git, modules)
  • Command palette (Ctrl+Shift+P) with fuzzy search
  • Configurable prompt with 10 presets
  • Kitty keyboard protocol support

IDE Integration

  • Full LSP server: hover, completions, go-to-definition, find references, rename, semantic tokens, signature help, formatting, code actions, inlay hints, call hierarchy
  • Source formatter (endo format) with idempotent round-trip
  • Debug Adapter Protocol (DAP) scaffolding

Cross-Platform

  • Linux, macOS, and Windows support
  • Platform abstraction layer for processes, pipes, TTY

Installation

Build from Source

The recommended way to obtain Endo today is to build from the Git repository:

git clone https://github.com/contour-terminal/endo.git
cd endo
cmake --preset clang-release
cmake --build --preset clang-release
sudo cmake --install build/clang-release

See the Getting Started guide for detailed prerequisites and build instructions.

On Linux, installing (from source or from the .deb/.rpm) also adds a desktop entry and the Endo icon to the freedesktop icon theme, so Endo shows up in application menus and launchers and opens in your terminal emulator.

Windows Installer (.msi)

Windows releases ship as an .msi installer. It installs Endo into a version-specific directory under C:\Program Files\Endo\ (for example C:\Program Files\Endo\1.2.3\) and adds that version's bin directory to the system PATH.

Because each version installs side by side in its own directory, you can upgrade or reinstall while Endo is still running -- the installer never replaces the locked, in-use binary, so it does not ask you to close running endo.exe processes or force a reboot. Running sessions keep working; you decide when to restart them. After an upgrade, the new version's bin is placed first on PATH, so endo resolves to the newest version, and the previous version's files are removed automatically (on the next reboot if it was still in use). See Platform Differences for setup details.

Configuring a terminal to launch Endo

The version-specific directory means an absolute path such as C:\Program Files\Endo\1.2.3\bin\endo.exe goes stale on the next upgrade. Use the latest link the installer maintains beside the version directories instead:

C:\Program Files\Endo\latest\bin\endo.exe

It is a directory junction, repointed at the version being installed on every install and removed on uninstall, so a terminal profile configured against it keeps working across upgrades. Windows Terminal needs this: it does not resolve a bare endo.exe through PATH. Anything that does resolve through PATH — a login shell, cmd, PowerShell — can simply use endo, since the installer puts the current version's bin first on the system PATH.

If you are upgrading from a pre-.msi Endo that was installed with the old .exe (NSIS) installer, the .msi automatically removes that installer's leftover C:\Program Files\Endo\bin entry from PATH. Its files (directly under C:\Program Files\Endo\) are not touched by the .msi; remove them with the old uninstaller or by hand if you no longer need them.

GitHub Repository

The source code, issue tracker, and development activity are hosted on GitHub:

github.com/contour-terminal/endo

Package Managers

Coming Soon

Package manager support is on the roadmap but not yet available.

Planned package manager support includes:

Package Manager Platform Status
Homebrew macOS, Linux Planned
Scoop Windows Planned
AUR Arch Linux Planned
APT / PPA Debian, Ubuntu Planned
RPM / COPR Fedora, RHEL Planned
Nix NixOS, any Planned

If you would like to help package Endo for your preferred distribution, contributions are welcome. See Contributing for details.

Versioning

Endo follows Semantic Versioning. Until the 1.0 release, the API and language syntax may change between minor versions. After 1.0, backward compatibility will be maintained within major versions.

Version metadata in the binary

endo --version prints the full descriptive version, for example 0.1.0-312-gfcf09f3e — release tag v0.1.0, 312 commits past it, at commit fcf09f3e. The same information is embedded as OS-level metadata, so tools that never run the binary can read it too:

Platform Mechanism How to read it
Windows VS_VERSION_INFO resource (Get-Command endo.exe).Version
macOS embedded __TEXT,__info_plist section otool -P $(which endo)
Linux .note.package ELF note (ELF package metadata) readelf -p .note.package $(which endo)

The embedded numeric version has four fields — MAJOR.MINOR.PATCH.COMMITS, so 0.1.0.312 above. The first three are the release tag's own components; the fourth is the number of commits since that tag, and is 0 for a release build.

This deliberately differs from the version the packages carry (0.1.312 for the same build — the MSI ProductVersion, the Program Files\Endo\<version>\ directory, the .deb/.rpm version). Windows Installer compares only three fields, so the packaged version has to fold the commit distance into the patch field to stay unique and increasing between releases. Binary metadata has a fourth field available and uses it, which keeps the release's real patch number visible. Releases built from a clean tag are unambiguous either way: 0.1.0 and 0.1.0.0.

Both are derived at configure time from git describe. Committing without re-running CMake leaves the previous commit count embedded until the next configure.

The Linux note's type field defaults to cmake; a distribution build can set -DENDO_PACKAGE_METADATA_TYPE=deb (or rpm, …) to identify the packaging it belongs to. The note is only emitted when the linker supports --package-metadata (GNU ld 2.39+, LLVM lld 15+); configure says so when it does not.