Lite XL plugins and the manifest that keeps a small editor's plugin list honest

A registry of pointers as much as a repository of plugins

The official registry for Lite XL describes itself simply as plugins for the Lite XL text editor, and it notes that it was originally forked from the rxi lite-plugins repository. That lineage explains the shape of the thing. Lite XL is a small editor written in C with a Lua runtime for its extensions, and the plugin ecosystem that grew around it was a plain list of links before it was a registry with rules.

The top-level entries show what the repository actually is: a .github/ directory, a .gitignore, a LICENSE, the README.md, a manifest.json, and a plugins/ directory. So it holds real plugin files locally as well as pointing at code hosted elsewhere. The distinction is not cosmetic, because the two kinds of entry are governed differently, and the rules are where the trust model lives.

An entry that points at a repository carries a remote, and the registry insists that the remote also pins a specific commit hash. An entry that is not hosted in a repository, only a url, must supply a checksum that matches the existing plugin. The plugin table marks entries hosted on external repositories with an asterisk, which is the only visible hint in the generated documentation that a given row behaves differently from the rest.

That is a small design with a clear purpose. A registry that lists third-party code is only useful if a user can tell what they are getting, and the two rules give that: a hash says exactly which revision you will run, and a checksum says the downloaded file is the one that was vetted.

The manifest is the source, and the table is a build artefact

The most consequential line in the documentation is the one telling contributors not to edit the README manually. The file is autogenerated from manifest.json, so to add a plugin you edit that file, following the Lite XL plugin manifest specification.

That inversion is worth dwelling on, because it is the difference between a list and a registry. If the README were the list, then adding a plugin and installing it would be the same operation, and the list would drift from what it describes. With a manifest as the source, the table is a rendering of structured metadata, and the metadata can carry fields that the prose table cannot express well, such as the pinned commit hash and the checksum.

The specification the project links lives in the lite-xl-plugin-manager repository, which means the registry and the package manager that consumes it agree on one schema rather than two. The plugin manager named in the same paragraph, lpm, is the tool that turns that schema into installations.

The documentation is also unusually blunt about what happens to submissions that do not fit. Any non-conforming pull request will not be accepted, and the table is updated automatically. There is no appeal process and no manual editing of the output, which means the rules have to be mechanical enough to check. A reviewer does not decide whether a plugin is good; a check decides whether the entry is well formed.

For a reader evaluating the project, that is the line to understand. This registry is a schema plus a set of automated checks plus a generated document. The curation it does is not aesthetic judgement, it is conformance.

Installing a plugin, and the three ways in

Installation is documented in two branches depending on what kind of entry you are installing, and a plugin manager gives you a third.

For an entry that links to a repository, the instruction is to follow that repository's own README, because the plugin lives there and the registry only indexes it. For a plugin that is a single file or a directory, you drop it directly into the plugins directory for your platform: on Linux and MacOS it is the same path, `~/.config/lite-xl/plugins/`, and on Windows it is `C:\Users\(username)\.config\lite-xl\plugins\`.

If you use a Lite XL plugin manager such as lpm, the install is a single command:

  lpm install plugin_name

The leading indentation there is how the documentation prints it, and the command itself is what you type.

That three-way split has a practical consequence worth naming. The registry cannot install anything by itself, because it is a list rather than a program. A plugin hosted in the registry's own plugins/ directory can be copied in by hand. A plugin hosted elsewhere has to be fetched from its own repository, and the pinned commit hash in the manifest is what tells a tool like lpm which revision to fetch. And the plugin manager is a separate project with its own release cycle, so the registry depends on it rather than containing it.

For someone who wants a plugin installed and working today, the local-copy route is the simplest, since the file lands in a directory the editor already scans. For someone who wants their plugin list reproducible across machines, the manager route is better, and the manifest's pinned hashes are what make it reproducible rather than merely convenient.

Automated update pull requests, and what they do not cover

The update story is where the registry differs most from a hand-curated list, and it is worth being precise about the mechanism.

Any commits specified with a remote are checked automatically for updates to the latest branch, and pull requests are created for them on a recurring basis to keep the entries current. Stubs can specify an alternate branch to follow with `extra.follow_branch`.

So the refresh is a bot, not a person. The consequence is that a plugin's entry moves forward because an automated check found a newer revision, and the human role is confined to reviewing and merging the generated pull request. That is a workable division when the plugin set is large and the updates are mechanical.

The `extra.follow_branch` field is the escape hatch, and it matters because the default of tracking the latest branch is not always what a plugin wants. A plugin whose author keeps a stable branch would otherwise have its pinned hash advanced onto a moving target.

What the mechanism does not cover is equally worth stating. The automation follows branches in the repositories it points at. It cannot follow a plugin that is not in a repository at all, and for those the checksum rule is the only guarantee available, which means the registry can verify that a file has not changed since it was listed but cannot offer it updates at all. A url-only plugin is therefore a frozen entry by construction.

There is a second limitation in the same area. The checksum requirement applies to plugins hosted with a url, and it must match the existing plugin, which means adding a new url-only plugin is possible but changing one is not a casual operation. The integrity guarantee is deliberately strict, at the cost of making that class of entry harder to move.

What the listed plugins actually do

The generated table shows the flavour of what the registry carries, and the entries are mostly small quality-of-life additions rather than large features.

align_carets aligns multiple carets and selections, which is the kind of thing that only matters once you are editing several places at once. autoinsert automatically inserts closing brackets and quotes, and also allows selected text to be wrapped with brackets or quotes. autosave saves files when they change, and autosaveonfocuslost is the more specific variant that saves files that were changed when the main window loses focus by switching to another application.

autowrap hardwraps lines automatically as you type. Then base16 appears as a theme manager with base16 colour schemes, and it is one of the entries carrying the asterisk, which means it lives on an external repository rather than in this one.

Two observations follow. First, the registry is biased towards small, self-contained Lua files that drop into a plugins directory, which is exactly what a small editor's extension model encourages. Second, the entries are ordered alphabetically and are described in a sentence each, so the table reads as a catalogue rather than a set of recommendations. There is no popularity ranking, no usage statistics and no editorial recommendation in the generated output, which is consistent with the registry's role as an index.

The practical value for a user is discoverability: a single place to find out what exists for Lite XL, and a list whose entries have already been checked for the schema requirements. The value for a plugin author is distribution, since the registry is where a Lite XL user is likely to look.

Where this registry is the wrong tool

Three limits follow from what the project is.

The first is that it is a list, not a package manager. Nothing in the repository installs anything, updates anything or resolves dependencies. That work belongs to a separate tool, and the registry's own contribution rules push you toward one if you have a manager, or toward copying files by hand if you do not. Users on platforms where a plugin manager is not available are copying files into a dot directory, and the registry does nothing to make that smoother.

The second is the tension between a curated registry and a plugin's own repository. A plugin hosted elsewhere gets its updates through generated pull requests against a pinned hash, which is convenient for the user and an extra channel to maintain for the plugin author. And a plugin author who wants to publish through this registry takes on the manifest format and the conformance rules, with rejection as the outcome for entries that do not fit. A registry that rejects non-conforming entries is only useful if it is trusted, and that trust comes from strictness rather than from leniency.

The third is the update cadence of the tooling around it. The repository was last pushed to on 2026-10-12 and publishes no GitHub releases, so there is no tagged version of the registry to pin, and the manifest specification it points at lives in a different repository with its own version. A user who wants a reproducible plugin set is depending on two projects' schemas and one tool's behaviour, with only one of them visible in the entry.

The alternative worth comparing is skipping the registry and installing plugins directly from their repositories, which is what the documentation itself suggests for entries that link to a repository. The difference in approach is that the registry adds the pinning and checksum guarantees and a discovery point, and in exchange it asks you to accept a curated subset and a bot-driven update flow.

Editorial conclusion

Lite XL plugins is a good fit for a Lite XL user who wants one curated list of plugins rather than hunting through individual repositories, because the registry ships local copies in its own plugins/ directory and enforces the pinning rules that make a third-party entry safe to install. It is a poor fit if you want to publish a plugin, because the list is deliberately narrow and non-conforming entries are rejected, and it is a poor fit if you need a plugin that has not been listed, since a registry is a curated subset by definition. Before installing anything from it, check whether the entry has an asterisk, because that marks a plugin hosted on an external repository, and read the manifest specification the project links rather than assuming the table in the README is the source of truth.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lite-xl/lite-xl-plugins on GitHub
4. README