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
  1. 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:

KeyDescription
nameThe name of the language
scopeA string like source.js that identifies the language. Currently, we strive to match the scope names used by popular TextMate grammars and by the Linguist library. Usually source.<name> or text.<name> in case of markup languages
injection-regexregex pattern that will be tested against a language name in order to determine whether this language should be used for a potential language injection site.
file-typesThe filetypes of the language, for example ["yml", "yaml"]. See the file-type detection section below.
shebangsThe interpreters from the shebang line, for example ["sh", "bash"]
rootsA set of marker files to look for when trying to find the workspace root. For example Cargo.lock, yarn.lock
auto-formatWhether to autoformat this language when saving
diagnostic-severityMinimal severity of diagnostic for it to be displayed. (Allowed values: Error, Warning, Info, Hint)
comment-tokenThe token to use as a comment-token
indentThe indent to use. Has sub keys unit (the text inserted into the document when indenting; usually set to N spaces or "\t" for tabs) and tab-width (the number of spaces rendered for a tab)
language-serverThe Language Server to run. See the Language Server configuration section below.
configLanguage Server configuration
grammarThe tree-sitter grammar to use (defaults to the value of name)
formatterThe formatter for the language, it will take precedence over the lsp when defined. The formatter must be able to take the original file as input from stdin and write the formatted file to stdout
text-widthMaximum line length. Used for the :reflow command and soft-wrapping if soft-wrap.wrap_at_text_width is set, defaults to editor.text-width

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:

KeyDescription
commandThe name of the language server binary to execute. Binaries must be in $PATH
argsA list of arguments to pass to the language server binary
timeoutThe maximum time a request to the language server may take, in seconds. Defaults to 20
language-idThe language name to pass to the language server. Some language servers support multiple languages and use this field to determine which one is being served in a buffer
environmentAny environment variables that will be used when starting the language server { "KEY1" = "Value1", "KEY2" = "Value2" }

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:

KeyDescription
nameThe name of the tree-sitter grammar
sourceThe method of fetching the grammar - a table with a schema defined below

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

KeyDescription
gitA git remote URL from which the grammar should be cloned
revThe revision (commit hash or tag) which should be fetched
subpathA path within the grammar directory which should be built. Some grammar repositories host multiple grammars (for example tree-sitter-typescript and tree-sitter-ocaml) in subdirectories. This key is used to point hx --grammar build to the correct path for compilation. When omitted, the root of repository is used

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.