Repository files navigation

Maintenance status: *The xi-editor project is currently discontinued. Although we will happily accept bug fixes, no new features are currently planned. You may be interested inthe Lapce editor, which can be considered a spiritual successor to the xi-editor.— The Editors

Note:This repo contains only the editor core, which is not usable on its own. For editors based on it, check out the list inFrontends.

The xi-editor project is an attempt to build a high quality text editor,using modern software engineering techniques. It is initially built formacOS, using Cocoa for the user interface. There are also frontends forother operating systems available from third-party developers.

Goals include:

• Incredibly high performance. All editing operations should commit and paintin under 16ms. The editor should never make you wait for anything.

• Beauty. The editor should fit well on a modern desktop, and not look like athrowback from the ’80s or ’90s. Text drawing should be done with the besttechnology available (Core Text on Mac, DirectWrite on Windows, etc.), andsupport Unicode fully.

• Reliability. Crashing, hanging, or losing work should never happen.

• Developer friendliness. It should be easy to customize xi editor, whetherby adding plug-ins or hacking on the core.

Learn more with the creator of Xi, Raph Levien, in thisRecurse Center Localhost talk.

Screenshot:

This repository is the core only. You'll also need a front-end, from the listbelow.

Xi-editor targets 'recent stable Rust'. We recommend installing viarustup.The current minimum supported version is 1.40.

To build the xi-editor core from the root directory of this repo:

> cd rust> cargo build

Here are some front-ends in various stages of development:

• xi-mac, the official macOS front-end.

• xi-gtk, a GTK+ front-end.

• xi-term, a text UI.

• xi-electron, a cross-platform front-end based on web-technologies.

• Tau, a GTK+ front-end written in Rust. Forked fromhttps://github.com/bvinc/gxi, which was abandoned.

• xi-win, an experimental Windows front-end written in Rust.

• kod, a terminal frontend written in Golang.

• xi-qt, a Qt front-end.

• vixi, a Vim like front-end in Rust.

The following are currently inactive, based on earlier versions of the front-endprotocol, but perhaps could be revitalized:

• xi_glium, anexperimental GL-based front-end in Rust.

• XiEditorVS2015, C#.

• xi-android, an Android frontend.

There are notes (I wouldn’t call itdocumentation at this point) on the protocol atfrontend.md. If you're working on a front-end, feel free tosend a PR to add it to the above list.

Here are some of the design decisions, and motivation why they shouldcontribute to the above goals:

• Separation into front-end and back-end modules. The front-end is responsible for presenting the user interface anddrawing a screen full of text. The back-end (also known as “core”) holds the file buffers and isresponsible for all potentially expensive editing operations.

• Native UI. Cross-platform UI toolkits never look and feel quite right. Thebest technology for building a UI is the native framework of the platform.On Mac, that’s Cocoa.

• Rust. The back-end needs to be extremely performant. In particular, itshould use little more memory than the buffers being edited. That level ofperformance is possible in C++, but Rust offers a much more reliable, andin many ways, higher level programming platform.

• A persistent rope data structure. Persistent ropes are efficient even forvery large files. In addition, they present a simple interface to theirclients - conceptually, they're a sequence of characters just like a string,and the client need not be aware of any internal structure.

• Asynchronous operations. The editor should never, ever block and prevent theuser from getting their work done. For example, autosave will spawn athread with a snapshot of the current editor buffer (the persistent ropedata structure is copy-on-write so this operation is nearly free), which canthen proceed to write out to disk at its leisure, while the buffer is stillfully editable.

• Plug-ins over scripting. Most text editors have an associated scriptinglanguage for extending functionality. However, these languages are usuallyboth more arcane and less powerful than “real” languages. The xi editor willcommunicate with plugins through pipes, letting them be written in anylanguage, and making it easier to integrate with other systems such asversion control, deeper static analyzers of code, etc.

• JSON. The protocol for front-end / back-end communication, as well asbetween the back-end and plug-ins, is based on simple JSON messages. Iconsidered binary formats, but the actual improvement in performance wouldbe completely in the noise. Using JSON considerably lowers friction fordeveloping plug-ins, as it’s available out of the box for most modernlanguages, and there are plenty of the libraries available for the otherones.

This is still a project in its early stages. The Mac build has basic editingfunctionality (it was used to write this README), but looks very spare andis still missing essentials such as auto-indent. At the moment, it’s expectedthat its main community will be developers interested in hacking on a texteditor.

The xi-editor project was started by Raph Levien but has since receivedcontributions from a number of other people. See theAUTHORSfile for details.

This project is licensed under the Apache 2license.

We gladly accept contributions via GitHub pull requests. Please seeCONTRIBUTING.md for more details.

If you are interested in contributing but not sure where to start, there is anactive Zulip channel at #xi-editor onhttps://xi.zulipchat.com. There is alsoa #xi channel on irc.mozilla.org. Finally, there is a subreddit at/r/xi_editor.