Arity

Appearance

Editor setup ​

Arity ships a language server, started with arity lsp (stdio, JSON-RPC). It offers formatting, diagnostics with quick fixes, hover, completion, signature help, go-to-definition and find-references, rename, document and workspace symbols, semantic tokens, folding and selection ranges, document links, document color swatches, inlay hints, and call and type hierarchy.

Editors can also start the server for .Rd and .rd files, making workspace symbol search available before you open an R file. Arity does not yet provide diagnostics, formatting, or other document features for Rd files.

Beyond the quick fixes attached to lint diagnostics, the server offers a cursor-context refactor that writes a roxygen2 skeleton for the function you are on; see the code action reference.

Configuration is read from an arity.toml discovered from each file's directory or, if no project config is found, from the file named by ARITY_CONFIG (see the configuration reference). The server rechecks config files on subsequent formatting requests and document edits, including a user config outside the workspace. A missing or invalid ARITY_CONFIG file causes formatting to be refused until the config is fixed.

VS Code/Positron ​

Install the Arity extension from the VS Code Marketplace or Open VSX. It bundles the arity binary (falling back to a download) and starts the language server automatically for R and Rd files. Editors that support VS Code extensions, such as Positron, work the same way.

To use a custom user config, add this to your user settings.json, then run Arity: Restart Server:

json
{
  "arity.serverEnv": {
    "ARITY_CONFIG": "P:/Softwares/arity.toml"
  }
}

Use an absolute path. Project configs take precedence over this fallback.

Using only some features ​

The formatter, linter, and language features share one server but can be turned off independently, so you can adopt just the parts you want:

  • arity.formatting.enable — use arity as a formatter.
  • arity.diagnostics.enable — show arity diagnostics (the linter).
  • arity.languageFeatures.enable — hover, completion, navigation, symbols, rename, code actions, semantic tokens, and the rest.

All three default to true. They are client-side gates, so the server keeps running and the toggles take effect without a restart or reinstall. For a formatter-only setup, turn off the other two:

json
{
  "arity.diagnostics.enable": false,
  "arity.languageFeatures.enable": false
}

Turning off arity.diagnostics.enable this way suppresses every diagnostic, including the syntax/parse errors that an arity.toml [lint] selection cannot silence. The arity.toml route stays the right tool when you want to keep parse errors but mute specific lint rules across every editor and the CLI.

Zed ​

Arity attaches to Zed's R language, which the R extension provides. Install that one first, then install Arity from the extensions view (zed: extensions in the command palette).

The Arity extension also recognizes .Rd and .rd files as Rd, so opening one starts the server for workspace symbol search.

Zed uses the arity on your PATH when there is one, and otherwise downloads the release binary matching your platform. Keeping Arity on the PATH is the better option on distributions that cannot run the generic release build, NixOS above all.

The R extension also ships r_language_server. Zed runs both servers unless you say otherwise, so name the ones you want and put Arity first when it should handle formatting, in settings.json:

json
{
  "languages": {
    "R": {
      "language_servers": ["arity-language-server", "r_language_server"],
      "formatter": "language_server",
      "format_on_save": "on"
    }
  }
}

To run Arity alone, drop "r_language_server" from the list.

Editor settings go under the server's id and act as fallbacks when the project has no arity.toml:

json
{
  "lsp": {
    "arity-language-server": {
      "settings": {
        "lineWidth": 100,
        "indentWidth": 2
      }
    }
  }
}

An arity.toml in the project is authoritative, so prefer the file when the whole team should share the behavior.

To point Zed at a particular binary, set binary.path:

json
{
  "lsp": {
    "arity-language-server": {
      "binary": { "path": "/opt/arity/bin/arity", "arguments": ["lsp"] }
    }
  }
}

arguments replaces the command line rather than extending it, so it has to keep naming a subcommand that speaks LSP.

The R extension recognizes files by .r or .R suffix. It does not assign its language to DESCRIPTION, so the Arity extension cannot attach to those files until Zed's R language definition covers them.

Neovim ​

Register arity with Neovim's built-in LSP client for R, DESCRIPTION, and Rd files:

lua
-- Neovim ships no filetype for DESCRIPTION, so give it one. The name is yours
-- to choose: arity routes on the file name, not on what the client calls it.
vim.filetype.add({ filename = { DESCRIPTION = "r-description" } })

vim.lsp.config("arity", {
  cmd = { "arity", "lsp" },
  filetypes = { "r", "r-description", "rhelp" },
  root_markers = { "arity.toml", "DESCRIPTION", ".git" },
})
vim.lsp.enable("arity")

The rhelp filetype starts Arity when you open an Rd file, making workspace symbol search available. Drop the vim.filetype.add line and keep only "r" in filetypes if you only want arity on .R files.

Format on save (optional):

lua
vim.api.nvim_create_autocmd("BufWritePre", {
  pattern = { "*.R", "DESCRIPTION" },
  callback = function() vim.lsp.buf.format() end,
})

The DESCRIPTION entry matters: without it, the file is attached to the server and linted but never formatted on save.

Helix ​

In ~/.config/helix/languages.toml:

toml
[language-server.arity]
command = "arity"
args = ["lsp"]

[[language]]
name = "r"
language-servers = ["arity"]
formatter = { command = "arity", args = ["format"] }
auto-format = true

To start Arity when you open an Rd file, add a separate language entry to the same file:

toml
[[language]]
name = "rd"
scope = "text.rd"
language-id = "rd"
file-types = ["Rd", "rd"]
roots = ["arity.toml", "DESCRIPTION", ".git"]
language-servers = ["arity"]

RStudio ​

The development R package provides a Format with arity addin and discovers arity.toml automatically. These features were added after the CRAN 0.1.0 release. Install the development version to use them; building from source requires Cargo and Rust 1.89 or newer:

r
install.packages("remotes")
remotes::install_github("jolars/arity-r")

Choose Format with arity from RStudio's Addins menu. It formats selected R code, or the whole document when nothing is selected, including unsaved edits and untitled R scripts. Changes remain in the editor for you to save. To assign a shortcut, open Tools > Modify Keyboard Shortcuts and search for the addin.

The addin discovers configuration from the document's directory, or the working directory for untitled buffers. It uses the nearest arity.toml, with ARITY_CONFIG as a fallback when no project config is found. Only formatting settings apply; file exclusions and lint configuration do not. See the R package documentation for configuration overrides and supported selections.

With the CRAN package, format saved files from the console:

r
arity::format_file("R/example.R")

This rewrites the file on disk. CRAN 0.1.0 takes formatting options as function arguments and does not discover arity.toml. The R package embeds the formatter, so neither installation needs the Arity CLI.

Other editors ​

Any LSP-capable editor can use arity by launching arity lsp over stdio for the r language. Point your client's R language-server command at arity with the lsp argument.

To get the DESCRIPTION features too, add the file to whatever the client uses to decide which documents to send. Arity decides the grammar from the file name, so the language id the client reports does not matter, and one that says r is still handled as DCF.

To start Arity from an Rd file, associate .Rd and .rd with the same server in your client's filetype or document selector settings. The rd language id also identifies pathless Rd buffers. This enables workspace symbol search without opening an R file first.

DESCRIPTION files ​

The server also serves a package's DESCRIPTION, which is a different grammar from R. There it offers the packaging diagnostics, completion of package names in Depends, Imports, Suggests, LinkingTo, and Enhances, and hover showing a dependency's installed version and title. An unsaved edit counts immediately, so adding a package to Imports clears the undeclared-dependency findings in the R files that use it without saving first.

The installed version is also shown inline, as an inlay hint after each dependency:

text
Imports:
    dplyr (>= 1.0.0) 1.1.4,
    rlang 1.1.4,

Only indexed packages get one, so a dependency you have not installed stays bare. Arity has no setting of its own for these — your editor's inlay hint switch (editor.inlayHints.enabled in VS Code) turns them off.

Diagnostics are reported only for a DESCRIPTION at a package root of its own, matching what arity lint walks. A complete miniature package under tests/testthat/ is fixture data for a test, so it stays quiet.

A DESCRIPTION is formatted too, by default, so format-on-save canonicalizes it the same way it canonicalizes your .R files. Set description = false under [format] in arity.toml to leave it alone.

Only whole-document formatting is offered: canonical field order is a property of the whole file, so editor.formatOnSaveMode: "modifications" (and format-selection generally) will not touch a DESCRIPTION.

Editors need to be told to send the file, since most do not recognize DESCRIPTION on their own. The VS Code extension does this for you; for the rest, see the sections below.

arity v0.29.0 · Released under the MIT license.