Download a package and extract it in /opt. Additionally, it's recommended to symlink it in /usr/local/bin:

cd /opt
sudo curl -Lo helix.tar.gz https://github.com/usagi-flow/evil-helix/releases/download/release-<VERSION>/helix-<ARCH>-<OS>.tar.gz
sudo tar -xf helix.tar.gz
cd /usr/local/bin
sudo ln -sv /opt/helix/hx .

evil-helix-bin is available in the AUR and can be installed using your favorite AUR helper. E.g.:

paru -S evil-helix-bin

These are the current differences compared to the upstream project:

• Vim keybindings (feel free to file an issue if you're missing certain bindings):
  • Commands: c, d, y, x
  • Modifiers: i
  • Motions: w, 0, $
• Basic Vim modeline support (#3)
• Adjusted defaults (511060a):
  • The Helix "SEL" mode is called "VIS"
  • The default theme is catppuccin_macchiato
  • Smart tab is disabled by default
• If color_modes is enabled, color the file type in the statusline as well (5503542)
• Minimalistic window separator (dd990ca)

This fork seeks to implement functionality as part of the editor, and make it configurable. The added functionality includes a Vim look-and-feel, but also other features.

In contrast, the upstream project, Helix, mostly limits its scope to its current core functionality, and defers further functionality to the future Scheme-based plugin system.

Compared to plugins, implementing features as part of the editor greatly improves performance, and avoids the risk of plugin compatibility issues.

In addition, sensible defaults are crucial: The editor must offer a wide range of tools for your job, but it must do what you expect an editor to do.

Scheme/Lisp should not be forced onto the user. It's error-prone and harder to read by humans, compared to Rust/TOML/Lua/...

If upstream Helix moves to a Scheme-based configuration, this project will seek to keep a user-friendly alternative.

This project is a "soft fork", i.e. it remains compatible with the upstream and regularly rebases its changes on top of the upstream master branch. New features should be carefully isolated from the upstream codebase in order to avoid conflicts.

Whether this project remains in this state will depend on how much this project's philosophy and the upstream project diverge, although a hard fork should be considered as a last resort.

Considering the kind and frequency of changes to this repository, it makes sense to release small changes often, rather than holding features back in large releases. Releases are currently tagged on-demand.

• Consider a better name for this project
  • Move the project into an organization
• Improve and stabilize the CI
• Introduce more Vim keybindings
• Implement more common/crucial features as part of the editor:
  • File tree (cf. upstream PR)
  • Light/dark mode support
• Maintain compatibility with upstream
  • Contribute features to upstream where possible
  • Ensure (through CI) that rebasing is always possible

Keep in mind the main branch is regularly being rebased onto the upstream master branch.