# xed, the Linux Mint text editor, and the plugin system behind its traditional interface

> xed is a small C-based GTK3 text editor in the Linux Mint X-Apps suite, built around a traditional desktop interface and an optional Python plugin layer. It fits users who want a familiar plain text editor with extras, but the documentation leaves several everyday questions unanswered.

**linuxmint/xed** — X-Apps [Text] Editor (Cross-DE, backward-compatible, GTK3, traditional UI)

- Repository: https://github.com/linuxmint/xed
- Website: https://xapp-project.org
- Stars: 558 · Forks: 118
- Language: C
- License: GPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/linuxmint-xed

## The X-Apps editor for people who want a classic text editor

xed is described in its own repository as an X-Apps text editor with a cross desktop environment build, backward compatibility, a GTK3 toolkit and a traditional user interface. The implementation is C, the licence is GPL-2.0 and the project page is xapp-project.org. That description matters more than it first appears. A traditional interface means menu bars, a preferences dialog and a plain text pane rather than a single chrome-less window, which is the arrangement many people are migrating away from on Linux desktops but which remains the least surprising choice for a system editor that ships as part of an operating system suite.

The README calls xed a small and lightweight text editor, and lists complete support for UTF-8 text, syntax highlighting, search and replace, printing with print preview, file revert and a complete preferences interface. That is the baseline of a competent plain text editor, not a modern IDE. The interesting part is the extension layer, and the interesting part for a reader deciding whether to switch is what the project does not claim. There is no mention of auto-pairing of brackets and quotes, no mention of a language server, no mention of session restore, and no mention of a project-wide symbol search. If your editing depends on those, read further before switching.

## The bundled plugin set and where Python comes into it

The README says the plugin system is configurable and carries optional Python support. The bundled plugins are listed by name: Change Case, Document Statistics, File Browser, Indent Lines, Insert Date/Time, Modelines, Save Without Trailing Spaces, Sort, Spell checker, Tag list and Word Completion. Reading that list tells you something about the intended workflow. Modelines and Save Without Trailing Spaces are the plugins that matter most for editing files that live under version control, because both of them change a file in ways a reviewer would notice.

The repository layout backs this up, with a top-level plugins directory alongside data, help, po, pixmaps and test directories, so the plugin system is a first class part of the tree rather than an add-on kept elsewhere. The optional wording on Python is the detail to plan around. Because Python support is described as optional, a build without it may expose fewer scriptable actions inside the editor, and the README does not document a configure flag that turns Python on or off. The build instructions below show only the prefix step, so treat the plugin feature set of your own build as something to confirm after installation rather than assume.

## Remote file editing is advertised but not explained

Remote file editing appears in the feature list of the README, alongside UTF-8 support and syntax highlighting, with no further description. There is no section explaining which protocols are supported, whether the connection is made through GVFS, whether authentication is handled by the desktop keyring, or how a remote session behaves when the connection drops mid-edit. The repository contains a tools directory, but the repository listing does not tie any specific tool to remote access, so nothing more precise can be claimed about the mechanism.

For an engineer evaluating this editor, that silence is the finding. Remote editing is the kind of capability that either becomes the reason you keep an editor or the reason you move on, and the documentation gives no way to tell which it would be for you. The safest route is to treat it as an unverified extra until you have opened a file over a connection in your own environment and checked the behaviour on a dropped link. If your work lives mostly on remote hosts, this is the first thing to test and the first thing to ask the maintainers about.

## Building xed from source with meson and ninja

The README gives a three step build sequence built around meson and ninja. The configure step places the build tree under a directory named build with a system prefix, the compile step drives ninja against that directory, and the install step runs the ninja install target through sudo. Each command is given in the README as a comment line beneath the numbered step it belongs to, so the sequence has to be reconstructed rather than copy pasted as one block.

The build dependencies are the practical obstacle. The tree includes meson.build, meson_options.txt and a debian directory, which tells you the project is packaged for Debian style systems, and a po directory tells you translation files are part of the build. Anyone on a distribution without the X-Apps packaging available should expect to resolve the GTK3 and Python development dependencies themselves, since the README does not enumerate them.

```bash
    1. run the 'configure' script
      # meson --prefix=/usr build
```

The configure step creates a build directory at the prefix you choose.

```bash
    2. build xed
      # ninja -v -C build
```

Ninja then compiles the tree and reports each command as it runs.

```bash
    3. install xed
      # sudo ninja install -v -C build
```

The install step copies the finished binary, its data files and the plugins into the prefix. After it completes, the editor should be available on the system path, and the first thing worth checking is that the bundled plugins, in particular the Spell checker and the File Browser, load correctly in your environment.

## The Debian package route and the three release branches

For Debian based distributions the README offers a different path. It asks you to run dpkg-buildpackage from the xed base directory, move up one level, install the resulting package, and then apply later changes by installing into the debian build directory with ninja. This route matters because the repository ships separate branches per target desktop environment. The recent releases list shows master.mint22 dated 2026-09-21, master.lmde7 dated 2026-09-21 and master.lmde6 dated 2025-08-26, so a Mint 22 user, an LMDE 7 user and an LMDE 6 user are each served by a different branch of the same tree rather than by one universal tarball.

The branch layout is the part to verify before you build. Choosing master.lmde6 for a newer system means carrying an older snapshot that stopped receiving pushes more than a year before the other two, and choosing the newest branch on an older system means the compatibility promise the project describes as backward compatible is being tested in reverse. Pick the branch that matches your own environment.

```bash
    1. run "dpkg-buildpackage" from the xed base directory
    2. cd ..
      # sudo dpkg -i *.deb
```

After the package installs, check which branch you are on before reporting a behaviour difference, since the three branches are not at the same commit.

## The cases where xed is the wrong editor

The clearest case against adoption is a workflow that depends on structure awareness. xed offers syntax highlighting, which colours code, but the README lists no symbol index, no goto definition and no language server integration. Word Completion is present as a plugin, which suggests word level completion from the buffer rather than symbol aware completion from a project index. On a large code base, that difference is the whole argument.

The second case is a user who wants to keep an old habits of editor configuration and expects them to carry over. The README documents a preferences interface but does not describe an import path for other editors' settings, and the file revert and modelines features operate inside the editor rather than as portable configuration.

The third case is anyone who needs a documented recovery path. The README does not document rollback, and nothing in the described feature set mentions an undo history view or a session recovery file. Editors built for long editing sessions usually describe such a feature explicitly, so its absence from the feature list is worth checking rather than assuming.

The fourth case is a platform assumption. The branches are named for Mint and LMDE, and the package route is Debian based, so the audience is a Linux desktop user inside that family.

## Where xed sits against gedit and the wider X-Apps set

The repository keeps copies of release notes for two other editors, NEWS.GEDIT and NEWS.PLUMA, which points to how closely xed tracks the wider ecosystem of desktop text editors it sits among. The practical difference between xed and that upstream line of thinking is the surface. xed keeps a traditional, backward compatible interface with a preferences dialog, theme selections and a bundled, curated plugin set, including a Spell checker and Word Completion that ship with the package rather than requiring a separate download.

That curation is the trade-off in both directions. You get a known set of plugins that work with the traditional layout and optional Python support, and you give up the larger plugin catalogue that a more modern editor tends to attract. Because the plugin list in the README is explicitly a subset, packaged with the project, it is a list of what you get rather than an exhaustive catalogue of what exists.

Maintenance: the repository is not archived, and the last push was on 2026-09-21, which is also the date of the master.mint22 and master.lmde7 releases. The third branch, master.lmde6, was last touched on 2025-08-26, so the LMDE 6 line is where the project is quietest.

## Conclusion

xed makes sense for Mint users who want the classic editor layout, a bundled plugin set and optional Python extension, and it is a poor fit for anyone expecting auto-pairing, project-wide navigation or a documented recovery path. Before adopting it, check three things: whether the plugin you need is in the bundled list or must be written yourself, whether your desktop environment needs one of the per-branch packages such as master.mint22, and whether the absence of any documented undo history or rollback procedure matches how you work.

## FAQ

### How do I build xed from source?

The README gives three steps: run the configure script with meson to create a build directory, compile with ninja against that build directory, then install with sudo ninja install through the same build directory. For Debian based systems it also documents building a package with dpkg-buildpackage and installing the resulting deb.

### Which plugins ship with xed, and is Python required?

The bundled plugins are Change Case, Document Statistics, File Browser, Indent Lines, Insert Date/Time, Modelines, Save Without Trailing Spaces, Sort, Spell checker, Tag list and Word Completion. The README describes the plugin system as configurable with optional Python support, so plan for the scriptable part of the plugin layer to depend on a build that includes Python.

### Which xed branch should I use for Mint 22 or LMDE?

The recent releases list shows a separate branch per target: master.mint22, master.lmde7 and master.lmde6, the first two released on 2026-09-21 and the last on 2025-08-26. Pick the branch that matches your own desktop environment rather than building from master by default.

### Can xed edit files on a remote machine?

Support for editing remote files is listed among the features in the README. The documentation does not explain which protocols are used or how a dropped connection is handled, so treat the capability as something to verify in your own environment before relying on it.

## Sources

- [License: GPL-2.0](https://github.com/linuxmint/xed/blob/master/LICENSE)
- [linuxmint/xed on GitHub](https://github.com/linuxmint/xed)
- [Project website](https://xapp-project.org)
- [README](https://github.com/linuxmint/xed/blob/master/README.md)
- [Releases](https://github.com/linuxmint/xed/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/linuxmint-xed