Helix

Docs for bleeding edge master can be found at https://docs.helix-editor.com/master.

See the usage section for a quick overview of the editor, keymap section for all available keybindings and the configuration section for defining custom keybindings, setting themes, etc. For everything else (e.g., how to install supported language servers), see the Helix Wiki.

Refer the FAQ for common questions.

Installing Helix

• Pre-built binaries
• Linux, macOS, Windows and OpenBSD packaging status
• Linux
  • Ubuntu
  • Fedora/RHEL
  • Arch Linux community
  • NixOS
  • AppImage
• macOS
  • Homebrew Core
• Windows
  • Winget
  • Scoop
  • Chocolatey
  • MSYS2
• Building from source
  • Configuring Helix's runtime files
  • Validating the installation
  • Configure the desktop shortcut

To install Helix, follow the instructions specific to your operating system. Note that:

• To get the latest nightly version of Helix, you need to build from source.

• To take full advantage of Helix, install the language servers for your preferred programming languages. See the wiki for instructions.

Pre-built binaries

Download pre-built binaries from the GitHub Releases page. Add the binary to your system's $PATH to use it from the command line.

Linux, macOS, Windows and OpenBSD packaging status

Helix is available for Linux, macOS and Windows via the official repositories listed below.

Linux

The following third party repositories are available:

Ubuntu

Helix is available via Maveonair's PPA:

sudo add-apt-repository ppa:maveonair/helix-editor
sudo apt update
sudo apt install helix

Fedora/RHEL

Helix is available via copr:

sudo dnf copr enable varlad/helix
sudo dnf install helix

Arch Linux community

Releases are available in the community repository:

sudo pacman -S helix

Additionally, a helix-git package is available in the AUR, which builds the master branch.

NixOS

Helix is available as a flake in the project root. Use nix develop to spin up a reproducible development shell. Outputs are cached for each push to master using Cachix. The flake is configured to automatically make use of this cache assuming the user accepts the new settings on first use.

If you are using a version of Nix without flakes enabled, install Cachix CLI and use cachix use helix to configure Nix to use cached outputs when possible.

AppImage

Install Helix using AppImage. Download Helix AppImage from the latest releases page.

chmod +x helix-*.AppImage # change permission for executable mode
./helix-*.AppImage # run helix

macOS

Homebrew Core

brew install helix

Windows

Install on Windows using Winget, Scoop, Chocolatey or MSYS2.

Winget

Windows Package Manager winget command-line tool is by default available on Windows 11 and modern versions of Windows 10 as a part of the App Installer. You can get App Installer from the Microsoft Store. If it's already installed, make sure it is updated with the latest version.

winget install Helix.Helix

Scoop

scoop install helix

Chocolatey

choco install helix

MSYS2

For 64-bit Windows 8.1 or above:

pacman -S mingw-w64-ucrt-x86_64-helix

Building from source

Clone the repository:

git clone https://github.com/helix-editor/helix
cd helix

Compile from source:

cargo install --path helix-term --locked

This command will create the hx executable and construct the tree-sitter grammars in the local runtime folder. To build the tree-sitter grammars requires a c++ compiler to be installed, for example gcc-c++.

💡 If you are using the musl-libc instead of glibc the following environment variable must be set during the build to ensure tree-sitter grammars can be loaded correctly:

RUSTFLAGS="-C target-feature=-crt-static"

💡 Tree-sitter grammars can be fetched and compiled if not pre-packaged. Fetch grammars with hx --grammar fetch (requires git) and compile them with hx --grammar build (requires a C++ compiler). This will install them in the runtime directory within the user's helix config directory (more details below).

Configuring Helix's runtime files

Linux and macOS

Either set the HELIX_RUNTIME environment variable to point to the runtime files and add it to your ~/.bashrc or equivalent:

HELIX_RUNTIME=/home/user-name/src/helix/runtime

Or, create a symlink in ~/.config/helix that links to the source code directory:

ln -s $PWD/runtime ~/.config/helix/runtime

Windows

Either set the HELIX_RUNTIME environment variable to point to the runtime files using the Windows setting (search for Edit environment variables for your account) or use the setx command in Cmd:

setx HELIX_RUNTIME "%userprofile%\source\repos\helix\runtime"

💡 %userprofile% resolves to your user directory like C:\Users\Your-Name\ for example.

Or, create a symlink in %appdata%\helix\ that links to the source code directory:

💡 On Windows, creating a symbolic link may require running PowerShell or Cmd as an administrator.

Multiple runtime directories

When Helix finds multiple runtime directories it will search through them for files in the following order:

1. runtime/ sibling directory to $CARGO_MANIFEST_DIR directory (this is intended for developing and testing helix only).
2. runtime/ subdirectory of OS-dependent helix user config directory.
3. $HELIX_RUNTIME.
4. runtime/ subdirectory of path to Helix executable.

This order also sets the priority for selecting which file will be used if multiple runtime directories have files with the same name.

Validating the installation

To make sure everything is set up as expected you should run the Helix health check:

hx --health

For more information on the health check results refer to Health check.

Configure the desktop shortcut

If your desktop environment supports the XDG desktop menu you can configure Helix to show up in the application menu by copying the provided .desktop and icon files to their correct folders:

cp contrib/Helix.desktop ~/.local/share/applications
cp contrib/helix.png ~/.icons # or ~/.local/share/icons

To use another terminal than the system default, you can modify the .desktop file. For example, to use kitty:

sed -i "s|Exec=hx %F|Exec=kitty hx %F|g" ~/.local/share/applications/Helix.desktop
sed -i "s|Terminal=true|Terminal=false|g" ~/.local/share/applications/Helix.desktop

Using Helix

• Registers
  • User-defined registers
  • Special registers
• Surround
• Selecting and manipulating text with textobjects
• Navigating using tree-sitter textobjects
• Moving the selection with syntax-aware motions

For a full interactive introduction to Helix, refer to the tutor which can be accessed via the command hx --tutor or :tutor.

💡 Currently, not all functionality is fully documented, please refer to the key mappings list.

Registers

In Helix, registers are storage locations for text and other data, such as the result of a search. Registers can be used to cut, copy, and paste text, similar to the clipboard in other text editors. Usage is similar to Vim, with " being used to select a register.

User-defined registers

Helix allows you to create your own named registers for storing text, for example:

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

If a register is selected 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

The system clipboard is not directly supported by a special register. Instead, special commands and keybindings are provided. Refer to the key map for more details.

The black hole register is a no-op register, meaning that no data will be read or written to it.

Surround

Helix includes built-in functionality similar to vim-surround. The keymappings have been inspired from vim-sandwich:

You can use counts to act on outer pairs.

Surround can also act on multiple selections. For example, to change every occurrence of (use) to [use]:

1. % to select the whole file
2. s to split the selections on a search term
3. Input use and hit Enter
4. mr([ to replace the parentheses with square brackets

Multiple characters are currently not supported, but planned for future release.

Selecting and manipulating text with textobjects

In Helix, textobjects are a way to select, manipulate and operate on a piece of text in a structured way. They allow you to refer to blocks of text based on their structure or purpose, such as a word, sentence, paragraph, or even a function or block of code.

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

💡 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!

Navigating using tree-sitter textobjects

Navigating between functions, classes, parameters, and other elements is possible using tree-sitter and textobject queries. For example to move to the next function use ]f, to move to previous class use [c, and so on.

For the full reference see the unimpaired section of the key bind documentation.

💡 This feature relies on tree-sitter textobjects and requires the corresponding query file to work properly.

Moving the selection with syntax-aware motions

Alt-p, Alt-o, Alt-i, and Alt-n (or Alt and arrow keys) allow you to move the selection according to its location in the syntax tree. For example, many languages have the following syntax for function calls:

func(arg1, arg2, arg3);

A function call might be parsed by tree-sitter into a tree like the following.

(call
  function: (identifier) ; func
  arguments:
    (arguments           ; (arg1, arg2, arg3)
      (identifier)       ; arg1
      (identifier)       ; arg2
      (identifier)))     ; arg3

Use :tree-sitter-subtree to view the syntax tree of the primary selection. In a more intuitive tree format:

            ┌────┐
            │call│
      ┌─────┴────┴─────┐
      │                │
┌─────▼────┐      ┌────▼────┐
│identifier│      │arguments│
│  "func"  │ ┌────┴───┬─────┴───┐
└──────────┘ │        │         │
             │        │         │
   ┌─────────▼┐  ┌────▼─────┐  ┌▼─────────┐
   │identifier│  │identifier│  │identifier│
   │  "arg1"  │  │  "arg2"  │  │  "arg3"  │
   └──────────┘  └──────────┘  └──────────┘

If you have a selection that wraps arg1 (see the tree above), and you use Alt-n, it will select the next sibling in the syntax tree: arg2.

// before
func([arg1], arg2, arg3)
// after
func(arg1, [arg2], arg3);

Similarly, Alt-o will expand the selection to the parent node, in this case, the arguments node.

func[(arg1, arg2, arg3)];

There is also some nuanced behavior that prevents you from getting stuck on a node with no sibling. When using Alt-p with a selection on arg1, the previous child node will be selected. In the event that arg1 does not have a previous sibling, the selection will move up the syntax tree and select the previous element. As a result, using Alt-p with a selection on arg1 will move the selection to the "func" identifier.

Keymap

• Normal mode
  • Movement
  • Changes
    • Shell
  • Selection manipulation
  • Search
  • Minor modes
    • View mode
    • Goto mode
    • Match mode
    • Window mode
    • Space mode
      • Popup
    • Unimpaired
• Insert mode
• Select / extend mode
• Picker
• Prompt

💡 Mappings marked (LSP) require an active language server for the file.

💡 Mappings marked (TS) require a tree-sitter grammar for the file type.

Normal mode

Movement

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

Changes

Shell

Selection manipulation

Search

Search commands all operate on the / register by default. To use a different register, use "<char>.

Minor modes

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

These modes (except command mode) can be configured by remapping keys.

View mode

Accessed by typing z in normal mode.

View mode is intended for scrolling and manipulating the view without changing the selection. The "sticky" variant of this mode (accessed by typing Z in normal mode) is persistent and can be exited using the escape key. This is useful when you're simply looking over text and not actively editing it.

Goto mode

Accessed by typing g in normal mode.

Jumps to various locations.

Match mode

Accessed by typing m in normal mode.

See the relevant section in Usage for an explanation about surround and textobject usage.

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

Window mode

Accessed by typing Ctrl-w in normal mode.

This layer is similar to Vim keybindings as Kakoune does not support windows.

Space mode

Accessed by typing Space in normal mode.

This layer is a kludge of mappings, mostly pickers.

💡 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

These mappings are in the style of vim-unimpaired.

Insert mode

Insert mode bindings are minimal by default. Helix is designed to be a modal editor, and this is reflected in the user experience and internal mechanics. Changes to the text are only saved for undos when escaping from insert mode to normal mode.

💡 New users are strongly encouraged to learn the modal editing paradigm to get the smoothest experience.

These keys are not recommended, but are included for new users less familiar with modal editors.

As you become more comfortable with modal editing, you may want to disable some insert mode bindings. You can do this by editing your config.toml file.

[keys.insert]
up = "no_op"
down = "no_op"
left = "no_op"
right = "no_op"
pageup = "no_op"
pagedown = "no_op"
home = "no_op"
end = "no_op"

Select / extend mode

Select mode echoes Normal mode, but changes any movements to extend selections rather than replace them. Goto motions are also changed to extend, so that vgl for example extends the selection to the end of the line.

Search is also affected. By default, n and N will remove the current selection and select the next instance of the search term. Toggling this mode before pressing n or N makes it possible to keep the current selection. Toggling it on and off during your iterative searching allows you to selectively add search terms to your selections.

Picker

Keys to use within picker. Remapping currently not supported.

Prompt

Keys to use within prompt, Remapping currently not supported.

Commands

Command mode can be activated by pressing :. The built-in commands are:

Language Support

The following languages and Language Servers are supported. To use Language Server features, you must first install the appropriate Language Server.

You can check the language support in your installed helix version with hx --health.

Also see the Language Configuration docs and the Adding Languages guide for more language configuration information.

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 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 and Helix's Migrating from Vim.

TODO: Mention textobjects, 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

💡 You can easily open the config file by typing :config-open within Helix normal mode.

Example config:

theme = "onedark"

[editor]
line-number = "relative"
mouse = false

[editor.cursor-shape]
insert = "bar"
normal = "block"
select = "underline"

[editor.file-picker]
hidden = false

You can use a custom configuration file by specifying it with the -c or --config command line argument, for example hx -c path/to/custom-config.toml. Additionally, you can reload the configuration file by sending the USR1 signal to the Helix process on Unix operating systems, such as by using the command pkill -USR1 hx.

Finally, you can have a config.toml local to a project by putting it under a .helix directory in your repository. Its settings will be merged with the configuration directory config.toml and the built-in configuration.

Editor

[editor] Section

[editor.statusline] Section

Allows configuring the statusline at the bottom of the editor.

The configuration distinguishes between three areas of the status line:

[ ... ... LEFT ... ... | ... ... ... ... CENTER ... ... ... ... | ... ... RIGHT ... ... ]

Statusline elements can be defined as follows:

[editor.statusline]
left = ["mode", "spinner"]
center = ["file-name"]
right = ["diagnostics", "selections", "position", "file-encoding", "file-line-ending", "file-type"]
separator = "│"
mode.normal = "NORMAL"
mode.insert = "INSERT"
mode.select = "SELECT"

The [editor.statusline] key takes the following sub-keys:

The following statusline elements can be configured:

[editor.lsp] Section

[editor.cursor-shape] Section

Defines the shape of cursor in each mode. Valid values for these options are block, bar, underline, or hidden.

💡 Due to limitations of the terminal environment, only the primary cursor can change shape.

[editor.file-picker] Section

Set options for file picker and global search. Ignoring a file means it is not visible in the Helix file picker and global search.

All git related options are only enabled in a git repository.

[editor.auto-pairs] Section

Enables automatic insertion of pairs to parentheses, brackets, etc. Can be a simple boolean value, or a specific mapping of pairs of single characters.

To disable auto-pairs altogether, set auto-pairs to false:

[editor]
auto-pairs = false # defaults to `true`

The default pairs are (){}[]''""``, but these can be customized by setting auto-pairs to a TOML table:

[editor.auto-pairs]
'(' = ')'
'{' = '}'
'[' = ']'
'"' = '"'
'`' = '`'
'<' = '>'

Additionally, this setting can be used in a language config. Unless the editor setting is false, this will override the editor config in documents with this language.

Example languages.toml that adds <> and removes ''

[[language]]
name = "rust"

[language.auto-pairs]
'(' = ')'
'{' = '}'
'[' = ']'
'"' = '"'
'`' = '`'
'<' = '>'

[editor.search] Section

Search specific options.

[editor.whitespace] Section

Options for rendering whitespace with visible characters. Use :set whitespace.render all to temporarily enable visible whitespace.

Example

[editor.whitespace]
render = "all"
# or control each character
[editor.whitespace.render]
space = "all"
tab = "all"
newline = "none"

[editor.whitespace.characters]
space = "·"
nbsp = "⍽"
tab = "→"
newline = "⏎"
tabpad = "·" # Tabs will look like "→···" (depending on tab width)

[editor.indent-guides] Section

Options for rendering vertical indent guides.

Example:

[editor.indent-guides]
render = true
character = "╎" # Some characters that work well: "▏", "┆", "┊", "⸽"
skip-levels = 1

[editor.gutters] Section

For simplicity, editor.gutters accepts an array of gutter types, which will use default settings for all gutter components.

[editor]
gutters = ["diff", "diagnostics", "line-numbers", "spacer"]

To customize the behavior of gutters, the [editor.gutters] section must be used. This section contains top level settings, as well as settings for specific gutter components as subsections.

Example:

[editor.gutters]
layout = ["diff", "diagnostics", "line-numbers", "spacer"]

[editor.gutters.line-numbers] Section

Options for the line number gutter

Example:

[editor.gutters.line-numbers]
min-width = 1

[editor.gutters.diagnostics] Section

Currently unused

[editor.gutters.diff] Section

Currently unused

[editor.gutters.spacer] Section

Currently unused

[editor.soft-wrap] Section

Options for soft wrapping lines that exceed the view width:

Example:

[editor.soft-wrap]
enable = true
max-wrap = 25 # increase value to reduce forced mid-word wrapping
max-indent-retain = 0
wrap-indicator = ""  # set wrap-indicator to "" to hide it

Themes

To use a theme add theme = "<name>" to the top of your config.toml file, or select it during runtime using :theme <name>.

Creating a theme

Create a file with the name of your theme as the file name (i.e mytheme.toml) and place it in your themes directory (i.e ~/.config/helix/themes or %AppData%\helix\themes on Windows). The directory might have to be created beforehand.

💡 The names "default" and "base16_default" are reserved for built-in themes and cannot be overridden by user-defined themes.

Overview

Each line in the theme file is specified as below:

key = { fg = "#ffffff", bg = "#000000", underline = { color = "#ff0000", style = "curl"}, modifiers = ["bold", "italic"] }

Where key represents what you want to style, fg specifies the foreground color, bg the background color, underline the underline style/color, and modifiers is a list of style modifiers. bg, underline 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"

For inspiration, you can find the default theme.toml here and user-submitted themes here.

Using the linter

Use the supplied linting tool to check for errors and missing scopes:

cargo xtask themelint onedark # replace onedark with <name>

The details of theme creation

Color palettes

It's recommended to define a palette of named colors, and refer to them in 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"

Keep in mind that the [palette] table includes all keys after its header, so it should be defined after the 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 modifier, provided they are supported by your terminal emulator.

💡 The underlined modifier is deprecated and only available for backwards compatibility. Its behavior is equivalent to setting underline.style="line".

Underline style

One of the following values may be used as a value for underline.style, providing it is supported by your terminal emulator.

Inheritance

Extend other themes by setting the inherits property to an existing theme.

inherits = "boo_berry"

# Override the theming for "keyword"s:
"keyword" = { fg = "gold" }

# Override colors in the palette:
[palette]
berry = "#2A2A4D"

Scopes

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

Syntax highlighting

These keys match tree-sitter scopes.

When determining styling for a highlight, the longest matching theme key will be used. For example, if the highlight is function.builtin.static, the key function.builtin will be used instead of function.

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

• attribute - Class attributes, HTML tag attributes

• type - Types

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

• constructor

• 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)

• label

• punctuation

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

• keyword

  • control
    • conditional - if, else
    • repeat - for, while, loop
    • import - import, export
    • return
    • exception
  • operator - or, in
  • directive - Preprocessor directives (#if in C)
  • function - fn, func
  • storage - Keywords describing how things are stored
    • type - The type of something, class, function, var, let, etc.
    • modifier - Storage modifiers like static, mut, const, ref, etc.

• operator - ||, +=, >

• function

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

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

  • builtin

• namespace

• special

• markup

  • heading
    • marker
    • 1, 2, 3, 4, 5, 6 - heading text for h1 through h6
  • list
    • unnumbered
    • numbered
    • checked
    • unchecked
  • bold
  • italic
  • strikethrough
  • link
    • url - URLs pointed to by links
    • label - non-URL link references
    • text - URL and image descriptions in links
  • quote
  • raw
    • inline
    • block

• diff - version control changes

  • plus - additions
  • minus - deletions
  • delta - modifications
    • moved - renamed or moved files/changes

Interface

These scopes are used for theming the editor interface:

• markup
  • normal
    • completion - for completion doc popup UI
    • hover - for hover popup UI
  • heading
    • completion - for completion doc popup UI
    • hover - for hover popup UI
  • raw
    • inline
      • completion - for completion doc popup UI
      • hover - for hover popup UI

Key remapping

Helix currently supports one-way key remapping through a simple TOML configuration file. (More powerful solutions such as rebinding via commands will be available in the future).

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

# At most one section each of 'keys.normal', 'keys.insert' and 'keys.select'
[keys.normal]
C-s = ":w" # Maps Ctrl-s to the typable command :w which is an alias for :write (save file)
C-o = ":open ~/.config/helix/config.toml" # Maps Ctrl-o to opening of the helix config file
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 Ctrl-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

Minor modes

Minor modes are accessed by pressing a key (usually from normal mode), giving access to dedicated bindings. Bindings can be modified or added by nesting definitions.

[keys.insert.j]
k = "normal_mode" # Maps `jk` to exit insert mode

[keys.normal.g]
a = "code_action" # Maps `ga` to show possible code actions

# invert `j` and `k` in view mode
[keys.normal.z]
j = "scroll_up"
k = "scroll_down"

# create a new minor mode bound to `+`
[keys.normal."+"]
m = ":run-shell-command make"
c = ":run-shell-command cargo build"
t = ":run-shell-command cargo test"

Special keys and modifiers

Ctrl, 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.

A list of commands is available in the Keymap documentation and in the source code at helix-term/src/commands.rs at the invocation of static_commands! macro and the TypableCommandList.

Languages

Language-specific settings and settings for language servers are configured in languages.toml files.

languages.toml files

There are three possible locations for a languages.toml file:

1. In the Helix source code, this lives in the Helix repository. It provides the default configurations for languages and language servers.

2. In your configuration directory. This overrides values from the built-in language configuration. For example to disable auto-LSP-formatting in Rust:

# in <config_dir>/helix/languages.toml

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

3. In a .helix folder in your project. Language configuration may also be overridden local to a project by creating a languages.toml file in a .helix folder. Its settings will be merged with the language configuration in the configuration directory and the built-in configuration.

Language configuration

Each language is configured by adding a [[language]] section to a languages.toml file. For example:

[[language]]
name = "mylang"
scope = "source.mylang"
injection-regex = "mylang"
file-types = ["mylang", "myl"]
comment-token = "#"
indent = { tab-width = 2, unit = "  " }
language-server = { command = "mylang-lsp", args = ["--stdio"], environment = { "ENV1" = "value1", "ENV2" = "value2" } }
formatter = { command = "mylang-formatter" , args = ["--stdin"] }

These configuration keys are available:

File-type detection and the file-types key

Helix determines which language configuration to use based on the file-types key from the above section. file-types is a list of strings or tables, for example:

file-types = ["Makefile", "toml", { suffix = ".git/config" }]

When determining a language configuration to use, Helix searches the file-types with the following priorities:

1. Exact match: if the filename of a file is an exact match of a string in a file-types list, that language wins. In the example above, "Makefile" will match against Makefile files.
2. Extension: if there are no exact matches, any file-types string that matches the file extension of a given file wins. In the example above, the "toml" matches files like Cargo.toml or languages.toml.
3. Suffix: if there are still no matches, any values in suffix tables are checked against the full path of the given file. In the example above, the { suffix = ".git/config" } would match against any config files in .git directories. Note: / is used as the directory separator but is replaced at runtime with the appropriate path separator for the operating system, so this rule would match against .git\config files on Windows.

Language Server configuration

The language-server field takes the following keys:

The top-level config field is used to configure the LSP initialization options. A format sub-table within config can be used to pass extra formatting options to Document Formatting Requests. For example with typescript:

[[language]]
name = "typescript"
auto-format = true
# pass format options according to https://github.com/typescript-language-server/typescript-language-server#workspacedidchangeconfiguration omitting the "[language].format." prefix.
config = { format = { "semicolons" = "insert", "insertSpaceBeforeFunctionParenthesis" = true } }

Tree-sitter grammar configuration

The source for a language's tree-sitter grammar is specified in a [[grammar]] section in languages.toml. For example:

[[grammar]]
name = "mylang"
source = { git = "https://github.com/example/mylang", rev = "a250c4582510ff34767ec3b7dcdd3c24e8c8aa68" }

Grammar configuration takes these keys:

Where source is a table with either these keys when using a grammar from a git repository:

Choosing grammars

You may use a top-level use-grammars key to control which grammars are fetched and built when using hx --grammar fetch and hx --grammar build.

# Note: this key must come **before** the [[language]] and [[grammar]] sections
use-grammars = { only = [ "rust", "c", "cpp" ] }
# or
use-grammars = { except = [ "yaml", "json" ] }

When omitted, all grammars are fetched and built.

Guides

This section contains guides for adding new language server configurations, tree-sitter grammars, textobject queries, and other similar items.

Adding new languages to Helix

In order to add a new language to Helix, you will need to follow the steps below.

Language configuration

1. Add a new [[language]] entry in the languages.toml file and provide the necessary configuration for the new language. For more information on language configuration, refer to the language configuration section of the documentation.
2. If you are adding a new language or updating an existing language server configuration, run the command cargo xtask docgen to update the Language Support documentation.

💡 If you are adding a new Language Server configuration, make sure to update the Language Server Wiki with the installation instructions.

Grammar configuration

1. If a tree-sitter grammar is available for the new language, add a new [[grammar]] entry to the languages.toml file.
2. If you are testing the grammar locally, you can use the source.path key with an absolute path to the grammar. However, before submitting a pull request, make sure to switch to using source.git.

Queries

1. In order to provide syntax highlighting and indentation for the new language, you will need to add queries.
2. Create a new directory for the language with the path runtime/queries/<name>/.
3. Refer to the tree-sitter website for more information on writing queries.

💡 In Helix, the first matching query takes precedence when evaluating queries, which is different from other editors such as Neovim where the last matching query supersedes the ones before it. See this issue for an example.

Common issues

• If you encounter errors when running Helix after switching branches, you may need to update the tree-sitter grammars. Run the command hx --grammar fetch to fetch the grammars and hx --grammar build to build any out-of-date grammars.
• If a parser is causing a segfault, or you want to remove it, make sure to remove the compiled parser located at runtime/grammars/<name>.so.

Adding textobject queries

Helix supports textobjects that are language specific, such as functions, classes, etc. These textobjects 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 to Helix. 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.

Queries for textobject based navigation

Tree-sitter based navigation in Helix is done using captures in the following order:

• object.movement
• object.around
• object.inside

For example if a function.around capture has been already defined for a language in its textobjects.scm file, function navigation should also work automatically. function.movement should be defined only if the node captured by function.around doesn't make sense in a navigation context.

Adding indent queries

Helix uses tree-sitter to correctly indent new lines. This requires a tree-sitter grammar and an indent.scm query file placed in runtime/queries/{language}/indents.scm. The indentation for a line is calculated by traversing the syntax tree from the lowest node at the beginning of the new line. Each of these nodes contributes to the total indent when it is captured by the query (in what way depends on the name of the capture).

Note that it matters where these added indents begin. For example, multiple indent level increases that start on the same line only increase the total indent level by 1.

Scopes

Added indents don't always apply to the whole node. For example, in most cases when a node should be indented, we actually only want everything except for its first line to be indented. For this, there are several scopes (more scopes may be added in the future if required):

• all: This scope applies to the whole captured node. This is only different from tail when the captured node is the first node on its line.

• tail: This scope applies to everything except for the first line of the captured node.

Every capture type has a default scope which should do the right thing in most situations. When a different scope is required, this can be changed by using a #set! declaration anywhere in the pattern:

(assignment_expression
  right: (_) @indent
  (#set! "scope" "all"))

Capture types

• @indent (default scope tail): Increase the indent level by 1. Multiple occurrences in the same line don't stack. If there is at least one @indent and one @outdent capture on the same line, the indent level isn't changed at all.

• @outdent (default scope all): Decrease the indent level by 1. The same rules as for @indent apply.

• @extend: Extend the range of this node to the end of the line and to lines that are indented more than the line that this node starts on. This is useful for languages like Python, where for the purpose of indentation some nodes (like functions or classes) should also contain indented lines that follow them.

• @extend.prevent-once: Prevents the first extension of an ancestor of this node. For example, in Python a return expression always ends the block that it is in. Note that this only stops the extension of the next @extend capture. If multiple ancestors are captured, only the extension of the innermost one is prevented. All other ancestors are unaffected (regardless of whether the innermost ancestor would actually have been extended).

Predicates

In some cases, an S-expression cannot express exactly what pattern should be matched. For that, tree-sitter allows for predicates to appear anywhere within a pattern, similar to how #set! declarations work:

(some_kind
  (child_kind) @indent
  (#predicate? arg1 arg2 ...)
)

The number of arguments depends on the predicate that's used. Each argument is either a capture (@name) or a string ("some string"). The following predicates are supported by tree-sitter:

• #eq?/#not-eq?: The first argument (a capture) must/must not be equal to the second argument (a capture or a string).

• #match?/#not-match?: The first argument (a capture) must/must not match the regex given in the second argument (a string).

Additionally, we support some custom predicates for indent queries:

• #not-kind-eq?: The kind of the first argument (a capture) must not be equal to the second argument (a string).

• #same-line?/#not-same-line?: The captures given by the 2 arguments must/must not start on the same line.