
Xi editor: A modern editor with a backend written in Rust - ivank
https://github.com/google/xi-editor
======
todd8
I've never constructed an editor -- but I have used one before ;) so I thought
I'd make a few suggestions about the architectural considerations off the top
of my head. I'm an Emacs user, but I'm very excited about NeoVim. It looks
like your project is another really interesting one. I hope it takes off.

I notice that you've choosen Rust as the programming language for the editor,
a fine choice. Performance appears to be a key factor in your choice of
language. However, realize that performance isn't the reason one should use
Rust or C++ for the backend of an editor. Let's go though some simple back of
the envelope calculations. A realistic goal for editors is to keep ordinary
command and keystroke latency under 100ms, this should appear to users as if
operations are performed instantaniously. You've picked a more aggressive goal
of a maximum latency of 16ms, so let's go with that.

Today, a slow processor runs perhaps 5,000,000,000 instructions per second
(speed of Raspberry Pi 2). By the time the editor is ready for general use,
most programmer's development systems will probably run something like 20
times faster or 100 Billion instructions per second. For this rough
calculation I'll use the speed of a Raspberry Pi 2. In 16ms that's 8 million
instructions.

What this means is that in the backend of the editor we have plenty of time to
perform the editing operations no matter what language is used _as long as it
is a straight code path through the editor_. The pedestrian operations of the
editor, like reading a keystroke or inserting a letter into the text don't
require Rust or C++ or C. They can be done with practically any programming
language, even a language that runs a hundred times slower than C++ like
Python. It is the iterated operations where performance will be a concern:
searching big files, complex regular expression searches, syntax highlighting
after each keystroke, autocomplete, refactoring, the GUI and interfacing to
the GUI.

I couldn't agree more with your requirement that the editor shouldn't hang or
crash or lose work. Further, a modern editor is a big project and won't gain
traction without additional contributors. From a performance perspective my
gut feeling is that any language that performs no worse than 10 times slower
than C is a fine choice. For safety, either managed memory (with GC etc.) or
an approach like Rust is essential to allow code to be contributed. The JVM
languages, while being attractive in many ways carry the burden of a big
infrastructure; Jetbrains has figured it out but even after all these years
Eclipse feels so klunky--this make me rule out Java, Clojure and Scala. I
think this leaves at least Rust, Go, OCaml, Common Lisp, Dart, and Swift. (I'd
probably pick Go hoping to get more contributors.)

What about ropes, a clever and much more modern data structure for holding
strings than ancient Emac's gap buffer. Ropes do indead have better asymptotic
performace for many of the _basic_ string operations: delete an arbitrary
character, insert a substring, etc. What about all of the other operations
that you'd like your editor to do? Fast searching, backwards or forwards?
Handling UTF-8? Doing regular expression matching. Ropes turn the text being
edited into a tree of text segments so high speed searching is much more
difficult. An abstraction layer over the data structure to make it appear to
be indexed like an ordinary array will make some things run much slower, for
example, Boyer-Moore string searches, regular expression searching (done for
code highlighting), etc.

Ropes or other persistent data structures for sequences will work because they
can present an abstract indexed access interface to the rest of the program,
but you will always be dealing with it though this abstraction layer just when
you'd rather not. Processors can move several bytes per instruction cycle so
the gap buffer can close it's gap while editing a 10MB file in less than a
millisecond. This leaves the data in one contiguous block. So for simple
things the gap buffer is much faster than rope structures because for most
simple activity all of the additions and deletions are at the cursor, where
the gap is located, and for complex things there is a 1ms overhead before the
operation starts (to close the gap) but then things run basically full
processor speed without the requirement to go though the abstraction layers.
The places where I see this as likely to be important in modern editors is in
the design of incremental backups, persistent text attributes, memory mapped
access to underlying files, and coordination with asynchronous plugins working
on the buffer. I'll be curious to see how this works out for Xi.

Keystrokes and plugins. Emacs can end up running lisp code, through a pretty
slow lisp interpreter, on every keystroke. It's completely imperceptable. So
performance isn't a reason to treat keybindings differently than other
plugins. The overhead of IPC to a plugin is measured in micro seconds.

While supporting Sublime Text keybindings is fine. The programmers most likely
to be sensitive to keybindings will probably want either Vim or Emacs
keybindings. A good way to support multiple keybindings will make the editor
appeal to a much broader set of users. Plugins seem ideal for this. A key
comes in, is processed by a plugin and a few elemental backend operations are
invoked by the plugin in response to the key. This seems completely
reasonable.

The real issue with plugins is direct access to the edit buffer if the plugins
run in a separate process and address space. This is complex especially if the
buffer is being accessed asynchronously. How is syntax highlighting done in a
plugin for example. Where does the syntax highlighting actually get stored?
Does the plugin have to be informed each time the user scrolls the screen or
types a key (probably yes). What asynchronous commands does the plugin send
back to the editor to update the display. Is there a separate plugin working
on autocomplete? Does it also have to parse the source code just like the
syntax highlighting plugin? Well those are things to figure out, but the
keystroke bindings seem much easier to address in a plugin. Plugins provide a
convienient place to address the semantic difference between a modal editing
model (used extensively by Vim and to a degree by Emacs editors) and the
underlying editor backends capabilities.

~~~
raphlinus
Thanks for your thoughtful comments. I'll try to address some.

Using ropes is a tradeoff. A gapped buffer is viable for the reasons you
state, but I think ropes come out ahead for what I'm trying to do. It's not so
much the cost of filling the gap, as that ropes really facilitate parallel,
incremental, and asynchronous computation. For example, I want the "save"
operation to write a snapshot of the current buffer to disk, while still being
fully editable. The snapshot operation is trivially easy and fast with
immutable ropes, but if you tried to hack something like that on top of a
gapped buffer, it would increase complexity dramatically.

If you look at the implementation of my Unicode line breaking algorithm,
you'll see that the indirection cost of the rope abstraction is minimal. In
fact, it _flies_ - in my tests, it's about 3x faster than ICU working on a
contiguous string. This is because it's able to work on a leaf at a time. The
same can be done for search, etc. Yes, it'll require some reimplementation of
string basics, but I personally find that kind of thing fun.

I'm still working out the plugin story. Quick answers to your questions
though. A syntax highlighting plugin sees a window of the source buffer
(effectively a cache, with invalidation by RPC). I'm thinking a contiguous
buffer for the window, not a rope - it'd be bounded by a few megs. For a huge
file, computing the syntax highlight of what's off screen can be slow. In no
case does it block typing, worst case there's a lag before the colors resolve.
The plugin sends the annotations back as rich-text spans, which are stored in
the core. Scrolling is instant and doesn't inform the plugin. The autocomplete
plugin will almost certainly be separate from the syntax highlighting one (but
presumably an author could create a combo plugin if it had advantages).

This doesn't address everything you brought up, but hope it helps illuminate
some of my thinking.

~~~
martanne
As the main developer of an editor (vis) using a similar segmented data
structure (a piece chain, similar to a rope, but storing the text junks in a
double linked list, thus asymptotically worse) I can attest that the
performance is generally very good. Some work will be required to adapt/write
a regexp library around some kind of iterator interface, but in general I
found that persistent data structures are very well suited for editors.

One problem with the gap buffer is that as soon as you have multiple
cursors/selections or in my case structural regular expression support, then
you have to move the gap around all the time. Also undo/redo support is simply
not as elegant as with a persistent data structure.

For syntax highlighting copying the relevant text region into a contiguous
memory block is simple and works well. For now I'm trying a completely
stateless approach to syntax highlighting i.e. the text coloring is always
completely recalculated. This trades highlighting accuracy for simplicity, but
in practice the results aren't too bad. Efficient syntax highlighting for huge
files is a hard problem.

------
fritzy
According to the feature-set, this is basically NeoVIM.

* Separation into front-end and back-end: NeoVIM does this. The UI uses the same interface a plugin does.

* Asynchronous operations: NeoVIM uses libuv to do this (same asynchronous C++ lib as NodeJS).

* Plug-ins over scripting: Yup, NeoVIM does this, as well as dropping vimscript (although it will compile vimscript into Lua for you).

* JSON: NeoVIM uses msgpack, which is significantly less overhead than JSON, but structure compatible.

The two other features listed are Rust and rope-structures, which are
implimentation specifics that don't affect users or plugin writers at all.

Edit: The more the merrier! And it's good to see more projects using Rust, but
I don't see this as a strong need. See [https://github.com/rogual/neovim-dot-
app](https://github.com/rogual/neovim-dot-app) for a nice native Mac UI
plugin/client for neovim.

~~~
raphlinus
NeoVIM is great, and obviously it has been inspiration. I think it remains to
be seen whether NeoVIM can deliver an experience that feels like a modern
editor. My experience is that projects which attempt to layer a GUI on top of
an existing, mature console UI end up leaking bits of the underlying UI. I'm
thinking mostly of the various TeX shells here.

A large part of my motivation for starting this project is to explore how
suitable Rust is for this kind of work. End users shouldn't have to care, they
should judge it strictly by the quality of what it delivers. But I'm hoping
this project will be interesting to Rust programmers for a number of reasons.

~~~
cyphar
I don't understand why people need a GUI to edit text. And while I donate to
the NeoVIM project, I don't really like that they are increasing
incompatibility with Vim in order to create a GUI layer. It also bothers me
that they didn't just use the GPLv2 (because I find the dual Vim-Apache
licensing troubling).

~~~
Myrmornis
Is your terminal program not a GUI? Or do you not run a graphical window
environment at all?

~~~
mikekchar
Not the OP, but a lot of people (myself included) have minimal mouse
interaction even when they use X-windows. For example, I use a tiling window
manager and only interact with it through the keyboard. I use urxvt as my
terminal emulator and while I suspect it has some kind of mouse support I have
no idea what it is because I have never used it. I have my web browser set up
so that as much as possible everything is controllable through the keyboard. I
move all my windows around, resize, hide, focus with the keyboard. I don't
have any menu bars at all. All of the apps I use I have hidden the menu bars
if I can because I don't use them.

So even with GUI apps, I tend not to use the GUI. I don't think I'm alone.
Virtually everything I run is either a terminal app to begin with or can run
from the terminal. I have tmux set up to work almost exactly like my X window
manager, so if I don't run X I barely notice. I'm just as productive without X
window as I am with it except for a very few things: browser, gimp, a few
games... Honestly I can't think of very much.

It's great that some people like GUIs. I used to use them a lot, but have
since found that I'm happier without them. The keyboard is not really a
discoverable UI device most of the time, but it can be ridiculously efficient
once you learn how to use it. I also have very poor eyesight, so that probably
predisposes me to using interfaces where I don't need to use my vision.

------
fernly
TIL: about the rope data structure[1]. Never heard of it in decades in the
industry.

Disagree with the comment "Cross-platform UI toolkits never look and feel
quite right." Qt, for one, uses the native toolkit on Mac and Windows and I
can't see a difference in look'n'feel.

[1]
[https://en.wikipedia.org/wiki/Rope_%28data_structure%29](https://en.wikipedia.org/wiki/Rope_%28data_structure%29)

~~~
coldtea
> _Qt, for one, uses the native toolkit on Mac and Windows and I can 't see a
> difference in look'n'feel._

QT interfaces stick out like a sore thumb on the Mac.

Unless you custom-skin them to the point that they still stick out, but they
at least don't fall into the Uncanny Valley.

~~~
mherrmann
Is there something in particular that annoys you about Qt interfaces? I'm just
launching a Qt app ([https://fman.io](https://fman.io)) and want to avoid any
unnecessary annoyances.

~~~
coldtea
I can't tell from this particular screenshot, but things I've seen in other QT
apps: widgets don't conform to all OS X standard behaviors (e.g. accepting
keyboard shortcuts, scrolling behavior like "rubber band scrolling" etc),
custom (Qt drawn) widgets with differing look from platform ones throwing you
off, lack of support for new features as they are introduced, like OS X native
full screen, etc. I'd say keyboard shortcuts and native widget behavior is the
#1 thing though, followed by looks.

> _Of course there are alternative file managers for other platforms. But none
> of them make you really go wow._

Btw, there are a couple for Mac too, in case you haven't seen them, e.g.:
[http://www.binarynights.com/forklift/](http://www.binarynights.com/forklift/)
, [http://mac.eltima.com/file-manager.html](http://mac.eltima.com/file-
manager.html) and
[http://www.cocoatech.com/pathfinder/](http://www.cocoatech.com/pathfinder/).

~~~
mherrmann
Thanks for your reply. I've taken down all the points you mentioned and will
keep an eye on them during development.

I know all the file managers you mentioned (my market research turned up 91
file managers available globally). I believe my point "don't really make you
go wow" still applies.

Thanks again! M

------
educar
Interesting this is a google project.

[https://github.com/google/xi-
editor/blob/master/rust/rope/sr...](https://github.com/google/xi-
editor/blob/master/rust/rope/src/rope.rs) was quite interesting to read (for
someone who has never looked into rust)

~~~
retbull
doesn't s/he say at the bottom that this isn't a google project?

~~~
raphlinus
It's a project by a Googler (me), but it's a personal (20%) project, not an
official Google one.

~~~
namelezz
What's your thought of Rust? What dev env did you use?

~~~
raphlinus
Rust is working out very well so far. If you look at the rope implementation,
you'll see that it's high level and mathematical almost like a functional
language, but performance is first-class. I'm also very much looking forward
to retrofitting parallelism using libraries such as Rayon and crossbeam. I'll
probably write a retrospective when I'm farther into the project.

My current development environment is just Sublime Text for the Rust parts,
and Xcode for the parts written in Swift.

~~~
wbond
If you are using the recently-added default Rust syntax for Sublime Text and
run into any issues, please let me know by filing an issue at
[https://github.com/sublimehq/Packages/issues](https://github.com/sublimehq/Packages/issues).

------
vintermann
First thought, yet another editor attempt, not even very far come yet, and
it's OSX only.

Rather nice font in the screenshots though. Then

> _The main author is Raph Levien._

Oh. Now I see why this is on hacker news. Now I'm interested too. If nothing
else, this will be gorgeous.

~~~
Spiritus
I've never heard of him, care to enlighten me?

~~~
Someone
[https://en.m.wikipedia.org/wiki/Raph_Levien](https://en.m.wikipedia.org/wiki/Raph_Levien)

~~~
loup-vaillant
[https://en.wikipedia.org/wiki/Raph_Levien](https://en.wikipedia.org/wiki/Raph_Levien)
?

~~~
sp332
That's the same article in a "desktop" view. Is that what you're asking?
Personally I prefer the mobile one.

~~~
loup-vaillant
I'm asking "why anything _but_ the default URL?"

I'm asking "why isn't this handled by freaking CSS? We have a goddam tag for
this!"

------
thedz
Interesting note: The author (Raph Levien) is also the creator of my defacto
programming font Inconsolata. Super cool.

------
hayd
Not to be confused with Yi: [https://github.com/yi-
editor/yi](https://github.com/yi-editor/yi)

~~~
cm3
Yep. I use Yi occasionally and it works well, but it needs more users to test
and report the rough edges. Though, it's excellent for writing support for new
languages, given that it's all Haskell.

------
_RPM
I don't believe that it being written in Rust is a feature. The language it's
written in is just an implementation detail.

~~~
yarrel
Rust is a cult though. This will get upvotes that just "re-implementation of
non-Emacs text editor" wouldn't.

~~~
akadien
I just came from a project where Rust was a cult. Everything was rewritten in
Rust even though much of the C code base worked very well. Because Rust!

I was interested in Rust before, but it now seems like Rust programmers are
like vegans (I have to hear about it every 10 minutes.)

~~~
59nadir
> I just came from a project where Rust was a cult. Everything was rewritten
> in Rust even though much of the C code base worked very well. Because Rust!

I'm not saying anything specifically about this case, because clearly the
information here is very limited, but there is a case to be made for rewriting
projects that work to increase maintainability in the future. Most newer
languages do have an edge in this department, as they are more conscious of
those issues.

There is sometimes the benefit of a rewrite regardless of language, as well;
cleaning stuff up, organizing stuff better because you now know better, etc..

------
lesbaker
I like the explicitly stated emphasis on performance and large file support in
the goals. I look forward to seeing this develop and will be following the
project (and test-driving it when I have time).

------
mwcampbell
Interesting architecture, having the core communicate with the GUI front-end
over pipes via JSON. That certainly eliminates a whole class of pain around
inter-language glue.

Any idea what language and APIs the Windows version will use? All of the
Microsoft-sanctioned choices for desktop apps (as opposed to the wanna-be
mobile/tablet platform introduced with Windows 8) are kind of sucky.

~~~
raphlinus
I've been playing a bit with the various choices (there are so many!) and am
leaning in the direction of C# + WPF + Windows.System.Media for the text
drawing. Using something based on DirectWrite rather than GDI+ is important to
me because of text rendering quality. I have basically ruled out Windows
Universal because it feels a lot clunkier.

But I'm very much open to ideas from more experienced Windows devs who
understand the tradeoffs better.

~~~
mwcampbell
WPF left a bad taste in my mouth because, as far as I can tell, it hastened
the obsolescence of my brother's laptop around 2011. [1] But then, maybe WPF 4
under Windows 7 would have been better on the same hardware. Impossible to say
now.

The best solution would probably be one that uses both DirectWrite and
Direct2D. WPF 4 uses DirectWrite, but AFAIK, it's still on top of the older
Direct3D-based milcore graphics system. But to use both DWrite and D2D, I
guess you'd have to get down and dirty with C++, or at least use a lot of
P/Invoke and COM interop in your C# code.

To be honest, I don't understand why GDI isn't good enough. Can you explain
what you find lacking in GDI's text rendering, or point me at an existing
explanation?

[1]:
[https://news.ycombinator.com/item?id=8444494](https://news.ycombinator.com/item?id=8444494)

~~~
raphlinus
The main thing I'd add to [http://www.basschouten.com/blog1.php/font-
rendering-gdi-vers...](http://www.basschouten.com/blog1.php/font-rendering-
gdi-versus-directwrite) is that DirectWrite looks very smooth on high-dpi
displays while GDI+ is quite grainy.

------
unimpressive
So what exactly does 'native' mean for Linux distros?

~~~
raphlinus
I'm leaning towards Gtk+ because I'm more familiar with it (I used to be very
involved in that community, in fact) and because I know its Unicode support is
good.

~~~
dman
Please consider Qt as well, the implementation is solid and its easy to make
apps that are performant and polished.

~~~
raphlinus
Qt 4 or 5? I had difficulty getting even "hello world" running in 5, and the
size of deploy binaries (~16M) was scary. Maybe that doesn't matter so much if
it'll primarily be using system libraries.

~~~
lmm
What went wrong with 5? And yeah use dynamic linking, that's what it's for.

~~~
raphlinus
The specific thing that went wrong was trying to use the homebrew version. 4
just worked out of the box, no hassle. I do of course have access to a Linux
machine, but it'd be convenient to do development on my Mac as well. I'm
willing to give it another shot but need to be convinced it's worthwhile.

~~~
lmm
Well, I think Qt looks really pretty and generally prefer Qt apps over GTK
versions. I find it nicer as a programmer too. I've known projects to migrate
from GTK to Qt (in particular Rosegarden, which used to have a great blog post
about how much nicer it made everything that I sadly can't find now) - looking
at
[https://www.wikivs.com/wiki/GTK_vs_Qt](https://www.wikivs.com/wiki/GTK_vs_Qt)
there's a big list of projects that have switched from GTK to Qt and none that
have gone in the other direction.

------
Myrmornis

      In particular, it should use little more memory
      than the buffers being edited.
    

I'm pretty sure memory footprint of a text editor is not a relevant concern on
modern laptops. Or is the idea that it will work on completely different low-
memory environments from what I'm thinking?

~~~
gnuvince
I can't remember where I heard this, but someone said once that better
performance opens up more, and sometimes new, ways to work with a program. I
use GNU Emacs myself, and I basically start it when I boot my laptop and never
shut it down, which means that sometimes it has an uptime of months. I will
also often not close buffers that I'm working on and can end up with hundreds
of buffers in Emacs. Yet, the performance is entirely unaffected (or at least,
the impact is below what this human can notice). If Xi is serious about
keeping memory usage low, these kinds of patterns of usage that I and many
other Emacs users have adopted are going to be viable; on the other hand, in
an editor like Atom, one should probably keep as few buffers opened as
possible.

------
eggy
Would this easily port to Windows or Linux? I put my iMac 2011 in storage, but
I would like to try this out to learn Rust and building a text editor in
general. I see 'other targets are planned'. Any time soon?

~~~
raphlinus
I'm hoping soon but make no promises.

~~~
eggy
No rush here. I would like to be able to play with the code and Rust. Thanks!

------
sitkack
If folks like Rust and want questions answered, check out the vibrant
[http://reddit.com/r/rust](http://reddit.com/r/rust)

------
anderspitman
Awesome. I've thought it would be fun to work on a simple editor based on
Rust. Something similar to Vim but without ViML. I really like the idea of
using pipes rather than committing to a single plugin language. I'll be very
interested to see how that works out in practice.

------
cm3
Nice project, but contributing to the project requires assiging copyright of
any patch to Google, which is the same flaw that exists with FSF projects and
a major blocking issue for many potential contributors. Google should make an
exception for personal-but-not-Google-company projects and get rid of it or at
least remove the copyright assignment clause. Nobody wants to contribute to a
project under license X and then have their contributions be relicensed under
Y.

------
stephenr
I haven't used a "text" editor (as compared to a full IDE) for quite a while.

Do any of the decent OS X -compatible editors have things like

\- find usage of a method/class/constant in a project

\- change method signature and have calls update

\- rename a class/method/constant/variable and have usages updated

This isn't a troll, I'm honestly asking. I'm using IDEA Ultimate at the moment
and it works fine, it just has the usual downsides for a Java app.

~~~
adrusi
Those would typically be considered features for an external tool, maybe with
the editor configured to provide an interface to those tools.

If you write java and value those features, though IDEA will be a better
experience.

~~~
stephenr
Really? An external tool that isn't a text based editor but does have in depth
knowledge of the code? I've never heard of such a thing.

Also for reference I don't really write Java. I write php, sql, shell scripts,
ldif files, html, occasionally JavaScript and/or css, lua...

~~~
pdpi
> An external tool that isn't a text based editor but does have in depth
> knowledge of the code?

It's called a "compiler" ;)

Jokes aside, here's a few tools that might give you an idea what's out there:

    
    
      - Racer for rust
      - Go fmt 
      - Youcompleteme
      - ghc-mod

~~~
stephenr
Right, so specific tools for Rust, Go and Haskell (none of which I use) that
maybe have some refactoring support? (The gofmt example I kept finding was
renaming a field in a struct)

Oh and a plugin specifically for Vim, so not an external tool at all..

So, basically the answer is the same as before: an IDE is still where it's at.

------
ArmandGrillet
Eager to see in which direction will head the project! Raph Levien seems an
extremely talented engineer but, as it is a "20% time" project, I am not sure
what is the expecting outcome of this editor. When the development of Atom
started it was clear that it would replace Sublime Text in the long term, here
I don't know if it will replace TextEdit or be the next big thing.

------
Scarbutt
What default key bindings will it follow? CUA?

~~~
raphlinus
I'm basically planning on following Sublime Text's keybindings except when
there's good reason not to.

~~~
evanrelf
I know you said you haven't worked on plugins yet, but do you think a Vim mode
would be possible through plugins?

~~~
raphlinus
I think a Vim mode will be possible one way or other. I'm not sure having all
interaction mediated by plugins is the best way to accomplish it.

------
username223
The "documentation" is just weird. It has Rust, ropes, and JSON! Okay, but is
it modal? Does it have syntax highlighting and debugger support? What kind of
editor is it trying to be? The docs say nothing relevant to whether or not I
would want to use it.

------
kingosticks
I've no exposure to Rust but is it accurate to compare it to C++ as offering a
much more reliable, and in many ways, higher level programming platform.

Are there some quick and simple examples of this?

~~~
Cyph0n
The main advantage is Rust's ownership model. It allows you to catch most
memory problems at compile time.

[https://doc.rust-lang.org/book/ownership.html](https://doc.rust-
lang.org/book/ownership.html)

~~~
akadien
And it's one of the languages features that has a very steep learning curve.
Rust forces your design into its model.

Interestingly, rustc also seems to generate programs that leak memory. I
recall an issue where the simple and venerable "hello world" program in Rust
(i.e., println!) had memory leaks.

~~~
steveklabnik
That shouldn't be true. Please file bugs!

~~~
akadien
It was fixed but isn't fixed. [https://github.com/rust-
lang/rust/issues/19776](https://github.com/rust-lang/rust/issues/19776)

~~~
steveklabnik
Great, thanks.

------
dj-wonk
What's the plan for plugins? Will they need to be compiled?

~~~
raphlinus
I haven't started implementing plugins yet, so details are still vague.
General thoughts, they communicate with the core through a simple JSON-based
protocol, so can be written in any language you like. I imagine Python will be
one of the popular choices. Among other things, they'll be able to annotate
the text with rich-text spans, for things like syntax coloring. Also, I'm
planning for them to be async, so they won't slow typing even when they're
busy computing.

~~~
martanne
How do you plan to encode binary data in your JSON-based protocol? Base64?
This will only increase the overhead.

While the human readability of JSON is nice, it has some serious flaws when
the goal is to handle arbitrary data.

I have yet to decide what kind of protocol to use in my own vis editor[1],
hence why I'm asking.

[1] [https://github.com/martanne/vis](https://github.com/martanne/vis)

------
ninjabeans
I like the design decisions.

Just a heads up, you misspelled "sparse" and accidentally a word after
"completely".

------
ywecur
How do you pronounce the name? X-I or Chi?

~~~
hnbro
or shii or zee or

------
Keats
Looks very neat! Found my Rust reading for the week.

