Xi: an editor for the next 20 years [video]

Xi creator did an amazing work implementing ropes (<a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;xi-editor&#x2F;tree&#x2F;master&#x2F;rust&#x2F;rope" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;xi-editor&#x2F;tree&#x2F;master&#x2F;rust&#x2F;rope</a>)<p>The design documents (<a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;xi-editor&#x2F;tree&#x2F;master&#x2F;doc&#x2F;rope_science" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;xi-editor&#x2F;tree&#x2F;master&#x2F;doc&#x2F;rope_sci...</a>) explaining the concepts and implementation details is a must for those who want to understand its core.<p>But I still have my regards regarding input latency being accredited only to the text editor. I recently switched back to Linux (nvim running on alacritty with tmux) and the latency issues magically disapeared. During my iterm2 (and even terminal) period on OSX I felt horrible lag during operations which I don&#x27;t even have time to blink with my current setup.<p>The last straw was once I found out iterm2 consuming 10% of my CPU in idle, the issue only happened when any non builtin font (menlo, monaco or courier) was used.

Presenter here, feel free to ask questions.<p>Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.

&quot;Platform text rendering (CoreText, DirectWrite) not performant enough&quot;<p>That above needs some reliable proof to be honest.<p>I am testing this claim with Sciter (<a href="https:&#x2F;&#x2F;sciter.com" rel="nofollow">https:&#x2F;&#x2F;sciter.com</a>)... On Windows Sciter uses Direct2D&#x2F;DirectWrite (with an option to render on DirectX device directly) and&#x2F;or Skia&#x2F;OpenGL. On Mac it uses Skia&#x2F;OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia&#x2F;OpenGL.<p>Here is full screen text rendering on DirectX surface using Direct2D&#x2F;DirectWrite primitives. Display is 192 ppi - 3840x2160:<p><a href="https:&#x2F;&#x2F;sciter.com&#x2F;temp&#x2F;plain-text-syntax.png" rel="nofollow">https:&#x2F;&#x2F;sciter.com&#x2F;temp&#x2F;plain-text-syntax.png</a><p>On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. CPU consumption is 6% as it constantly does rendering in a &quot;game event loop&quot; style. In reality (render on demand as in sciter.exe) CPU consumption is 3% on kinetic scroll (120 FPS).<p>As you see platform text rendering is quite capable of drawing texts on modern hardware.<p>As of problems of text layouts ... Not that CPU and memory consuming too to be honest.<p>Sciter uses custom ::mark(name) pseudo-elements that allow to style arbitrary text runs&#x2F;ranges without the need of creating artificial DOM elements (like &lt;span&gt; for each &quot;string&quot; in MS Visual Code), see: <a href="https:&#x2F;&#x2F;sciter.com&#x2F;tokenizer-mark-syntax-colorizer&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sciter.com&#x2F;tokenizer-mark-syntax-colorizer&#x2F;</a><p>To try this by yourself: get <a href="https:&#x2F;&#x2F;github.com&#x2F;c-smile&#x2F;sciter-sdk&#x2F;blob&#x2F;master&#x2F;bin&#x2F;32&#x2F;sciter-dx.exe" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;c-smile&#x2F;sciter-sdk&#x2F;blob&#x2F;master&#x2F;bin&#x2F;32&#x2F;sci...</a> (sciter on DirectX) and sciter.dll nearby. Download <a href="https:&#x2F;&#x2F;github.com&#x2F;c-smile&#x2F;sciter-sdk&#x2F;blob&#x2F;master&#x2F;samples&#x2F;%2Bcolororizer&#x2F;show-master-css.htm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;c-smile&#x2F;sciter-sdk&#x2F;blob&#x2F;master&#x2F;samples&#x2F;%2...</a> and open it with the sciter-dx.exe.

There finally starts to be consciousness about input and output latency for GUI applications.<p>Xi sounds like an editor I&#x27;d love to use. Latency while typing is a jarring experience.

Pragmatically speaking the issue with switching editors is the fact that if it is not emacs or vi it is not a default install on whatever you sit down at.<p>I have tried tons of editors, and I always come back to vim. Heck, I have even moved my .vimrc to be the simplest possible with the smallest number of plugins.

I&#x27;m so conflicted about this. On one hand, having the &quot;engine&quot; written in Rust, and the frontend written in language suitable for writing a GUI, per platform, is a sound architectural choice. On the other hand, if there&#x27;s one type of open source applications we have enough to choose from already, it&#x27;s editors. If it&#x27;s for fun and the educational process, then by all means, that&#x27;s swell.<p>Bui if it&#x27;s because the world needs yet another editor, just because it can be written in Rust, I&#x27;m not so sure.

Just today I was trying to edit a 15MB JSON file and it was so terribly slow with Sublime Text and wondered if there was something faster out there.<p>Edit: So I built Xi-Mac and the file opens in a fraction vs ST3 but once it&#x27;s open performance is just as bad or maybe even worse.

Async and CRDT to coordinate between core and plugins is super clever and seems scalable to future design choices. Levien calls out that there is a high complexity overhead to this architecture, but that it&#x27;s probably worth it to maintain performance.

&gt; Separation into front-end and back-end modules.<p>That solves a lot of the Emacs trouble iiuc. (Same for the Async first design).<p>&gt; The xi editor will communicate with plugins through pipes, letting them be written in any language,<p>That&#x27;s caused a lot of trouble for vi&#x2F;vim, has it not? I get the separation of concerns, but intermingling the concerns has helped emacs in a certain way.

Great stuff, and awesome to see this coming from Google (and in Rust instead of Go). Interesting historical note: The author of Sublime Text left Google to work on it by himself when he couldn&#x27;t get it approved as a 20% project.

If I understand this correctly Xi and Alacritty are both using OpenGL to do the rendering and recently I heard that Rust supports compiling to Web Assembly.<p>Sounds as if it should be easy to port those apps to the browser world (WebGL + Web Assembly)? Does anybody know of any plans to do just that?

I&#x27;m glad `xi` is separating the editor core from the UI.<p>This feels more correct. So the GUI authors can work on the chrome and polish, while the editor team focus on performance and all the nitty-gritty memory operations.

Never I would have guessed that &quot;xi&quot; is pronounces &quot;gsai&quot;. I would pronounce it &quot;shee&quot; (like chinese) or &quot;ksai&quot; (english) or &quot;ksee&quot; (german).<p>Also, I don&#x27;t thin we need another editor with a pluggable focus. It&#x27;s not true that you need plugins to a text editor. It is plugged into an environment that also contains all the other things you need. It interacts via &quot;open file&quot;, &quot;read file&quot;, &quot;write file&quot; and &quot;close file&quot; with the other tools. It basically _IS_ the plugin for editing files.<p>And if you really want an editor containing plugins, then there&#x27;s a load of it out there. You can start with all the IDEs, you can start with Emacs, you can start even with Neovim or Atom. This is not a feature that needs another project.

Comment of the author of iterm2 on HN, about latency optimization: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14800195" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14800195</a>

I sure did like the core&lt;—&gt;core communicating idea for multiple users of a single document. It seemed like an easy trap to imagine X11 as the f&#x2F;e, b&#x2F;e, plugins, async were talked about, but not “just” using a remote f&#x2F;e to communicate w a remote core was sort of enlightening (having fell into the X11 trap as the talk was progressing).<p>Question re: json communication though: is there a space for something like protocol buffers here, or is that a case of YAGNI, or simply ill-suited?

Great work. I love the plug-ins not being tied to a specific language. Surprised about doing rpc within a text editor but it was well argued in the presentation. If I consider it within the context of the tooling in an IDE it totally makes sense.<p>Text editors running on the desktop that are based on web browsers was a big step backwards. It encouraged features&#x2F;plugins but now my text editor and my chat client each take gigabytes to run!

Emacs: an editor for last 20 years and next 20 years.

Super cool! I hope you find someone to unfuck the WYSIWYG UX. (I&#x27;m hoping your markdown will be both, markdown and WYSI-nearly-WYG)

How small the binaries are, with a GUI (GTK, KDE, or QT), if I need to install in a system with no root permissions (local install) that&#x27;s what I like about sublime, I can install it in home directory without needing admin help.<p>would you support plugins in a scripting language like python?

What methods and tools were used to capture and collect the per-frame tracing? It looked cool and really clearly presented, I would love to use that myself.

Tried it, xi-mac, though trips over a minimised font awesome css here, not even with all fonts, locks&#x2F;freeze all other open windows.

Trying to build it, but I get<p>error: could not find `Cargo.toml` in `&#x2F;home&#x2F;xyz&#x2F;Downloads&#x2F;xi-editor-0.2.0` or any parent directory

What&#x27;s the best Windows build for this?

I wonder if the name is a tip of the hat to China and their leader. Anyone know?

Nice ideas, but it&#x27;s a shame that Rust is barely portable.

You should change your video in my opinion. Especially the intro part it kinda made me roll my eyes.

VI(m) has been around for a long time now....

&gt; <i>modern text editor with uncompromising performance</i><p>Solution in search of a problem.<p>I haven&#x27;t run into an editor performance issue in more than twenty years.<p>I will gladly trade a hundred text editor performance fixes for one <i>web browser performance fix</i>.

not to be confused with the yi editor <a href="https:&#x2F;&#x2F;duckduckgo.com&#x2F;?q=yi+editor&amp;atb=v59-2__&amp;ia=software" rel="nofollow">https:&#x2F;&#x2F;duckduckgo.com&#x2F;?q=yi+editor&amp;atb=v59-2__&amp;ia=software</a>

Xi looks great, has a very clever design, and clearly is a next generation platform for building a useful and powerful editor.<p>I&#x27;d love to see this project continue and be a success. I think there is plenty of room for yet another text editor.<p>Here&#x27;s where I&#x27;m going to be a bit of a party pooper.<p>Pragmatically speaking all of the great stuff Raph is talking about doesn&#x27;t really matter. What Raph cares about are the kind of things people who build text editors like to geek out on and again that&#x27;s all great.<p>Imma let you finish but VSCode and Atom and the entire Electron ecosystem have once again proven that a sub-optimal but powerful platforms with low barriers to entry win most of the time.<p>I&#x27;m rarely impressed by software projects (close or open) and I&#x27;m even less often impressed by Microsoft but what they&#x27;ve been able to do with VSCode in such a short amount of time, and the VELOCITY with which they are continuing to move means that for all practical purposes I will probably be in an Electron based editor for the foreseeable future.<p>I&#x27;m not saying I don&#x27;t want Xi to continue to grow and be as great as it can be, I&#x27;m just being pragmatic.