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.

Installation

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

OSX

Helix is available in homebrew-core:

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 with nix develop.

Flake 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 you can install Cachix cli; cachix use helix will configure Nix to use cached outputs when possible.

Arch Linux

Releases are available in the community repository.

A helix-git package is also available on the AUR, which builds the master branch.

Fedora Linux

You can install the COPR package for Helix via

sudo dnf copr enable varlad/helix
sudo dnf install helix

Void Linux

sudo xbps-install helix

Build from source

git clone 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 its 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 overridden via the HELIX_RUNTIME environment variable.

To use Helix in desktop environments that supports XDG desktop menu, including Gnome and KDE, copy the provided .desktop file to the correct folder:

cp contrib/Helix.desktop ~/.local/share/applications

To use another terminal than the default, you will need to 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

Please note: there is no icon for Helix yet, so the system default will be used.

Finishing up the installation

To make sure everything is set up as expected you should finally run the helix healthcheck via

hx --health

For more information on the information displayed in the health check results refer to Healthcheck.

Building tree-sitter grammars

Tree-sitter grammars must 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).

Installing language servers

Language servers can optionally be installed if you want their features (auto-complete, diagnostics etc.). Follow the instructions on the wiki page to add your language servers of choice.

Usage

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

See tutor (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 selections (yay!). For example, to change every occurrence 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.

Syntax-tree Motions

A-p, A-o, A-i, and A-n (or Alt and arrow keys) move the primary selection according to the selection's place in the syntax tree. Let's walk through an example to get familiar with them. Many languages have a syntax like so 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"  │
   └──────────┘  └──────────┘  └──────────┘

Say we have a selection that wraps arg1. The selection is on the arg1 leaf in the tree above.

func([arg1], arg2, arg3)

Using A-n would select the next sibling in the syntax tree: arg2.

func(arg1, [arg2], arg3)

While A-o would expand the selection to the parent node. In the tree above we can see that we would select 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. If we have a selection on arg1, A-p would bring us to the previous child node. Since arg1 doesn't have a sibling to its left, though, we climb the syntax tree and then take the previous selection. So A-p will move the selection over to the "func" identifier.

[func](arg1, arg2, arg3)

Textobjects

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

Tree-sitter Textobject Based Navigation

Navigating between functions, classes, parameters, etc is made possible by leveraging tree-sitter and textobjects queries. For example to move to the next function use ]f, to move to previous class use [c, and so on.

See the unimpaired section of the keybind documentation for the full reference.

NOTE: This feature is dependent on tree-sitter based textobjects and therefore requires the corresponding query file to work properly.

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 filetype.

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. Use "<char> to operate on a different one.

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 relevant 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

Insert mode bindings are somewhat minimal by default. Helix is designed to be a modal editor, and this is reflected in the user experience and internal mechanics. For example, changes to the text are only saved for undos when escaping from insert mode to normal mode. For this reason, 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.

If you want to disable them in insert mode as you become more comfortable with modal editing, you can use the following in your config.toml:

[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

This 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 :, similar to Vim. Built-in commands:

Language Support

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

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

Hint: 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 may also specify a file to use for configuration with the -c or --config CLI argument: hx -c path/to/custom-config.toml.

It is also possible to trigger configuration file reloading by sending the USR1 signal to the helix process, e.g. via pkill -USR1 hx. This is only supported on unix operating systems.

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. Note that due to limitations of the terminal environment, only the primary cursor can change shape. Valid values for these options are block, bar, underline, or hidden.

[editor.file-picker] Section

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.

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

Themes

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

Creating a theme

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). The directory might have to be created beforehand.

The names "default" and "base16_default" are reserved for the builtin themes and cannot be overridden by user defined themes.

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

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.

Inheritance

Extend upon 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.

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.

• attribute - Class attributes, html tag attributes

• type - Types

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

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

• namespace

• markup

  • heading
    • marker
    • 1, 2, 3, 4, 5, 6 - heading text for h1 through h6
  • list
    • unnumbered
    • numbered
  • bold
  • italic
  • 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

You can check compliance to spec with

cargo xtask themelint onedark  # replace onedark with <name>

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]
C-s = ":w" # Maps the Control-s to the typable command :w which is an alias for :write (save file)
C-o = ":open ~/.config/helix/config.toml" # Maps the Control-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 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

NOTE: Typable commands can also be remapped, remember to keep the : prefix to indicate it's a typable command.

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 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 languages.toml files. The first is compiled into Helix and lives in the Helix repository. This provides the default configurations for languages and language servers.

You may define a languages.toml in your configuration directory which 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

Language configuration may also be overridden local to a project by creating a languages.toml file under a .helix directory. 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"] }
formatter = { command = "mylang-formatter" , args = ["--stdin"] }

These configuration keys are available:

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

Adding languages

Language configuration

To add a new language, you need to add a [[language]] entry to the languages.toml (see the language configuration section).

When adding a new language or Language Server configuration for an existing language, run cargo xtask docgen to add the new configuration to the Language Support docs before creating a pull request. When adding a Language Server configuration, be sure to update the Language Server Wiki with installation notes.

Grammar configuration

If a tree-sitter grammar is available for the language, add a new [[grammar]] entry to languages.toml.

You may use the source.path key rather than source.git with an absolute path to a locally available grammar for testing, but switch to source.git before submitting a pull request.

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.

NOTE: When evaluating queries, the first matching query takes precedence, which is different from other editors like Neovim where the last matching query supersedes the ones before it. See this issue for an example.

Common Issues

• If you get errors when running after switching branches, you may have to update the tree-sitter grammars. Run hx --grammar fetch to fetch the grammars and hx --grammar build to build any out-of-date grammars.

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

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.

Queries for Textobject Based Navigation

Tree-sitter based navigation 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 it's 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.