Installation

We provide pre-built binaries on the GitHub Releases page.

OSX

A Homebrew tap is available:

brew tap helix-editor/helix
brew install helix

Linux

NixOS

A flake containing the package is available in the project root. The flake can also be used to spin up a reproducible development shell for working on Helix.

Arch Linux

Releases are available in the community repository.

Packages are also available on AUR:

• helix-bin contains the pre-built release
• helix-git builds the master branch

Build from source

git clone --recurse-submodules --shallow-submodules -j8 https://github.com/helix-editor/helix
cd helix
cargo install --path helix-term

This will install the hx binary to $HOME/.cargo/bin.

Helix also needs it's runtime files so make sure to copy/symlink the runtime/ directory into the config directory (for example ~/.config/helix/runtime on Linux/macOS). This location can be overriden via the HELIX_RUNTIME environment variable.

Usage

(Currently not fully documented, see the keymappings list for more.)

See tutor.txt (accessible via hx --tutor or :tutor) for a vimtutor-like introduction.

Registers

Vim-like registers can be used to yank and store text to be pasted later. Usage is similar, with " being used to select a register:

• "ay - Yank the current selection to register a.
• "op - Paste the text in register o after the selection.

If there is a selected register before invoking a change or delete command, the selection will be stored in the register and the action will be carried out:

• "hc - Store the selection in register h and then change it (delete and enter insert mode).
• "md - Store the selection in register m and delete it.

Special Registers

There is no special register for copying to system clipboard, instead special commands and keybindings are provided. See the keymap for the specifics. The black hole register works as a no-op register, meaning no data will be written to / read from it.

Surround

Functionality similar to vim-surround is built into helix. The keymappings have been inspired from vim-sandwich:

• ms - Add surround characters
• mr - Replace surround characters
• md - Delete surround characters

ms acts on a selection, so select the text first and use ms<char>. mr and md work on the closest pairs found and selections are not required; use counts to act in outer pairs.

It can also act on multiple seletions (yay!). For example, to change every occurance of (use) to [use]:

• % to select the whole file
• s to split the selections on a search term
• Input use and hit Enter
• mr([ to replace the parens with square brackets

Multiple characters are currently not supported, but planned.

Textobjects

Currently supported: word, surround, function, class, parameter.

• ma - Select around the object (va in vim, <alt-a> in kakoune)
• mi - Select inside the object (vi in vim, <alt-i> in kakoune)

Note: f, c, etc need a tree-sitter grammar active for the current document and a special tree-sitter query file to work properly. Only some grammars currently have the query file implemented. Contributions are welcome !

Migrating from Vim

Helix's editing model is strongly inspired from vim and kakoune, and a notable difference from vim (and the most striking similarity to kakoune) is that Helix follows the selection → action model. This means that the whatever you are going to act on (a word, a paragraph, a line, etc) is selected first and the action itself (delete, change, yank, etc) comes second. A cursor is simply a single width selection.

See also Kakoune's Migrating from Vim.

TODO: Mention texobjects, surround, registers

Configuration

To override global configuration parameters, create a config.toml file located in your config directory:

• Linux and Mac: ~/.config/helix/config.toml
• Windows: %AppData%\helix\config.toml

Editor

[editor] section of the config.

[editor.filepicker] section of the config. Sets options for file picker and global search. All but the last key listed in the default file-picker configuration below are IgnoreOptions: whether hidden files and files listed within ignore files are ignored by (not visible in) the helix file picker and global search. There is also one other key, max-depth available, which is not defined by default.

LSP

To display all language server messages in the status line add the following to your config.toml:

[lsp]
display-messages = true

Themes

First you'll need to place selected themes in your themes directory (i.e ~/.config/helix/themes), the directory might have to be created beforehand.

To use a custom theme add theme = <name> to your config.toml or override it during runtime using :theme <name>.

The default theme.toml can be found here, and user submitted themes here.

Creating a theme

First create a file with the name of your theme as file name (i.e mytheme.toml) and place it in your themes directory (i.e ~/.config/helix/themes).

Each line in the theme file is specified as below:

key = { fg = "#ffffff", bg = "#000000", modifiers = ["bold", "italic"] }

where key represents what you want to style, fg specifies the foreground color, bg the background color, and modifiers is a list of style modifiers. bg and modifiers can be omitted to defer to the defaults.

To specify only the foreground color:

key = "#ffffff"

if the key contains a dot '.', it must be quoted to prevent it being parsed as a dotted key.

"key.key" = "#ffffff"

Color palettes

It's recommended define a palette of named colors, and refer to them from the configuration values in your theme. To do this, add a table called palette to your theme file:

ui.background = "white"
ui.text = "black"

[palette]
white = "#ffffff"
black = "#000000"

Remember that the [palette] table includes all keys after its header, so you should define the palette after normal theme options.

The default palette uses the terminal's default 16 colors, and the colors names are listed below. The [palette] section in the config file takes precedence over it and is merged into the default palette.

Modifiers

The following values may be used as modifiers.

Less common modifiers might not be supported by your terminal emulator.

Scopes

The following is a list of scopes available to use for styling.

Syntax highlighting

These keys match tree-sitter scopes.

For a given highlight produced, styling will be determined based on the longest matching theme key. For example, the highlight function.builtin.static would match the key function.builtin rather than function.

We use a similar set of scopes as SublimeText. See also TextMate scopes.

• type - Types

  • builtin - Primitive types provided by the language (int, usize)

• constant (TODO: constant.other.placeholder for %v)

  • builtin Special constants provided by the language (true, false, nil etc)
    • boolean
  • character
    • escape
  • numeric (numbers)
    • integer
    • float

• string (TODO: string.quoted.{single, double}, string.raw/.unquoted)?

  • regexp - Regular expressions
  • special
    • path
    • url
    • symbol - Erlang/Elixir atoms, Ruby symbols, Clojure keywords

• comment - Code comments

  • line - Single line comments (//)
  • block - Block comments (e.g. (/* */)
    • documentation - Documentation comments (e.g. /// in Rust)

• variable - Variables

  • builtin - Reserved language variables (self, this, super, etc)
  • parameter - Function parameters
  • other
    • member - Fields of composite data types (e.g. structs, unions)
  • function (TODO: ?)

• label

• punctuation

  • delimiter - Commas, colons
  • bracket - Parentheses, angle brackets, etc.

• keyword

  • control
    • conditional - if, else
    • repeat - for, while, loop
    • import - import, export
    • (TODO: return?)
  • directive - Preprocessor directives (#if in C)
  • function - fn, func

• operator - ||, +=, >, or

• function

  • builtin
  • method
  • macro
  • special (preprocesor in C)

• tag - Tags (e.g. <body> in HTML)

• namespace

Interface

These scopes are used for theming the editor interface.

Keymap

• Mappings marked (LSP) require an active language server for the file.
• Mappings marked (TS) require a tree-sitter grammar for the filetype.

Normal mode

Movement

NOTE: Unlike vim, f, F, t and T are not confined to the current line.

Changes

Shell

Selection manipulation

Search

Minor modes

These sub-modes are accessible from normal mode and typically switch back to normal mode after a command.

View mode

View mode is intended for scrolling and manipulating the view without changing the selection. The "sticky" variant of this mode is persistent; use the Escape key to return to normal mode after usage (useful when you're simply looking over text and not actively editing it).

Goto mode

Jumps to various locations.

Match mode

Enter this mode using m from normal mode. See the relavant section in Usage for an explanation about surround and textobject usage.

TODO: Mappings for selecting syntax nodes (a superset of [).

Window mode

This layer is similar to vim keybindings as kakoune does not support window.

Space mode

This layer is a kludge of mappings, mostly pickers.

TIP: Global search displays results in a fuzzy picker, use space + ' to bring it back up after opening a file.

Popup

Displays documentation for item under cursor.

Unimpaired

Mappings in the style of vim-unimpaired.

Insert Mode

Select / extend mode

I'm still pondering whether to keep this mode or not. It changes movement commands (including goto) to extend the existing selection instead of replacing it.

NOTE: It's a bit confusing at the moment because extend hasn't been implemented for all movement commands yet.

Picker

Keys to use within picker. Remapping currently not supported.

Prompt

Keys to use within prompt, Remapping currently not supported.

Key Remapping

One-way key remapping is temporarily supported via a simple TOML configuration file. (More powerful solutions such as rebinding via commands will be available in the future).

To remap keys, write a config.toml file in your helix configuration directory (default ~/.config/helix in Linux systems) with a structure like this:

# At most one section each of 'keys.normal', 'keys.insert' and 'keys.select'
[keys.normal]
a = "move_char_left" # Maps the 'a' key to the move_char_left command
w = "move_line_up" # Maps the 'w' key move_line_up
"C-S-esc" = "extend_line" # Maps Control-Shift-Escape to extend_line
g = { a = "code_action" } # Maps `ga` to show possible code actions
"ret" = ["open_below", "normal_mode"] # Maps the enter key to open_below then re-enter normal mode

[keys.insert]
"A-x" = "normal_mode" # Maps Alt-X to enter normal mode
j = { k = "normal_mode" } # Maps `jk` to exit insert mode

Control, Shift and Alt modifiers are encoded respectively with the prefixes C-, S- and A-. Special keys are encoded as follows:

Keys can be disabled by binding them to the no_op command.

Commands can be found at Keymap Commands.

Commands can also be found in the source code at helix-term/src/commands.rs at the invocation of commands! macro.

Hooks

Languages

Language-specific settings and settings for particular language servers can be configured in a languages.toml file placed in your configuration directory. Helix actually uses two languages.toml files, the first one is in the main helix repository; it contains the default settings for each language and is included in the helix binary at compile time. Users who want to see the available settings and options can either reference the helix repo's languages.toml file, or consult the table in the adding languages section.

Changes made to the languages.toml file in a user's configuration directory are merged with helix's defaults on start-up, such that a user's settings will take precedence over defaults in the event of a collision. For example, the default languages.toml sets rust's auto-format to true. If a user wants to disable auto-format, they can change the languages.toml in their configuration directory to make the rust entry read like the example below; the new key/value pair auto-format = false will override the default when the two sets of settings are merged on start-up:

# in <config_dir>/helix/languages.toml

[[language]]
name = "rust"
auto-format = false

Guides

This section contains guides for adding new language server configurations, tree-sitter grammers, textobject queries, etc.

Adding languages

Submodules

To add a new langauge, you should first add a tree-sitter submodule. To do this, you can run the command

git submodule add -f <repository> helix-syntax/languages/tree-sitter-<name>

For example, to add tree-sitter-ocaml you would run

git submodule add -f https://github.com/tree-sitter/tree-sitter-ocaml helix-syntax/languages/tree-sitter-ocaml

Make sure the submodule is shallow by doing

git config -f .gitmodules submodule.helix-syntax/languages/tree-sitter-<name>.shallow true

or you can manually add shallow = true to .gitmodules.

languages.toml

Next, you need to add the language to the languages.toml found in the root of the repository; this languages.toml file is included at compilation time, and is distinct from the language.toml file in the user's configuration directory.

These are the available keys and descriptions for the file.

Queries

For a language to have syntax-highlighting and indentation among other things, you have to add queries. Add a directory for your language with the path runtime/queries/<name>/. The tree-sitter website gives more info on how to write queries.

Common Issues

• If you get errors when building after switching branches, you may have to remove or update tree-sitter submodules. You can update submodules by running

  git submodule sync; git submodule update --init
  

• Make sure to not use the --remote flag. To remove submodules look inside the .gitmodules and remove directories that are not present inside of it.

• If a parser is segfaulting or you want to remove the parser, make sure to remove the submodule and the compiled parser in runtime/grammar/<name>.so

• The indents query is indents.toml, not indents.scm. See this issue for more information.

Adding Textobject Queries

Textobjects that are language specific (like functions, classes, etc) require an accompanying tree-sitter grammar and a textobjects.scm query file to work properly. Tree-sitter allows us to query the source code syntax tree and capture specific parts of it. The queries are written in a lisp dialect. More information on how to write queries can be found in the official tree-sitter documentation.

Query files should be placed in runtime/queries/{language}/textobjects.scm when contributing. Note that to test the query files locally you should put them under your local runtime directory (~/.config/helix/runtime on Linux for example).

The following captures are recognized:

Example query files can be found in the helix GitHub repository.