1. 83

  2. 41

    Thanks to the Recurse Center for inviting me to speak and for making the video. I’m here if anyone has questions.

    1. 21

      A very non-technical question: Why should Xi “only” be an editor for the next 20 years? In terms of text editors, that’s not that long. People, like me, use Editors that are nearly twice as old as I am, and the reasons don’t seem to be tied to performance or the internal structure of the implementations, but rather a core “philosophy” regarding how things are done, or how the programmer should relate to text. What does Xi have to offer regarding these “practical” qualities, that have made, for example Emacs or Vi(m) last for so long? Does Xi see itself in such a certain tradition, having a certain ideal that you aspire to, or do you set your own terms? These could seem important if one intends to write an editor that should be practically used, which is what I gathered from the video, as opposed to being a “purely academic” experiment, which would obviously have different goals and priorities.

      1. 4

        Do you plan on doing a Linux frontend yourself and would it matter performance-wise? I saw that some people are working on a gtk+ frontend but I was wondering if it will be as fast as the mac one.

        1. 4

          In my ideal world, there’d be a cross-fertilization of code and ideas so the linux front-end would be just as nice and performant as the mac one, but it’s unlikely at this point I’ll take it on myself.

          1. 2

            I just tried xi-gtk and it’s very fast. Not sure what it’s like compared to the swift one but it’s a whole lot faster than gedit.

            1. 1

              nice, thanks!

          2. 4

            Also, here is a cool demo of async loading of big text files – you can navigate and I think even edit while loading:


            Using immer, Clojure-like immutable data structures in C++:


            The editor is a demo of the library: https://github.com/arximboldi/ewig

            1. 3

              I just watched the video. It looks really interesting, although a lot of it was over my head!

              I more or less understand the process model, async architecture, and distributed data structures. I like that part – very Unix-y.

              But there were a lot of rendering terms I didn’t understand. Maybe because some of it is Mac-specific. But also some of the OpenGL issues. Is there any background material on text rendering you’d recommend?

              Also, I don’t understand the connection to Fuschia? I was under the impression that Fuschia was more consumer-facing, and Xi is more developer-facing. That is, I imagine most consumers don’t have text editors installed. There is no text editor on Android or ChromeOS.

              Or is xi more general than a vi/emacs replacement – is it meant to be used as part of a browser for implementing text boxes?

              1. 4

                Glad you enjoyed the talk!

                Unfortunately, there really isn’t a lot of material on text processing, especially from a modern perspective. A lot of what I learned about rendering came from reading other code (alacritty in particular), and talking to people like Patrick Walton and my teammates on Chrome and Android.

                There is an EditText widget on Android (a good chunk of my career involved working on it), but you certainly wouldn’t want to write code (or long-form text) in it. My goal with xi is to make a core lightweight and performant enough it can be used in such cases, easily embedded in apps, yet powerful enough for cases where you really do need a dedicated editor application.

              2. 2

                I feel like it’s fairly out of my league, but I’ve been thinking about implementing a Sublime Text-like editor (multiple cursors, smart brackets/quotation marks) for arbitrary text fields in web sites. Would it be possible to use Xi as a backend for something like that? Perhaps via compilation to WASM?

                1. 8

                  Eventually it is my hope that something like that could work. There are some technical details (the current implementation uses threads), so it’s not an easy project. In the meantime, the excellent CodeMirror does multiple selections, and is very widely used embedded in websites.

              3. 26

                I should have trademarked while I had the chance…

                1. 8

                  The general approach reminded me of the X Window System: a client-server architecture and a very general design with the additional focus on performance. I was surprised that this was not lead by a study of the operations that an editor should support based on the tasks a user has. Are multiple cursors a new promising way? Should we better support fuzzy search beyond regexp? We probably want handling of variable-width fonts and font attributes. How to integrate IDE-like features? How to handle tables and images? Equations? Isn’t this also an aspect of performance: how fast a task can be solved given the tools available?

                  1. 9

                    We’re thinking about most of those questions. I personally think multiple cursors are very powerful and useful, but recognize this is a question of user preference. Rich text (including variable width) is high on the roadmap, and support for Language Server not far behind. I’m not sure about equations, that seems possibly beyond the scope of the project, but it might be interesting to see how far that could go as a plugin.

                    And yes, how fast you can get your work done is ultimately the proper measure. It’s just a little harder to quantify, even with an Arduino :)

                  2. 4

                    I have no specific questions but I wanted to say how much I enjoyed the talk, and how much I look forward to the time when I can brew cask install xi and act as your alpha tester.

                    1. 2

                      If you’re interested in playing around with Xi on a mac, you should check out xi-mac. It doesn’t have much complex tooling but it does use CoreText which is pretty interesting, and in general is a very smooth feeling editor (compared to say, Atom).

                      1. 1

                        Yeah, I looked at it! But I couldn’t build it, because I only have the commandline tools, and it requires full Xcode.

                      2. 1

                        Pretty much I am in the same boat as Peter, both for Xi and Alacritty! Since I am no Rust dev (yet ;)) I feel like it’s too early for me to use it, but I check both projects on Github once in a while.

                      3. 3

                        Title reminded me of this talk on Emacs, titled “The Editor of a Lifetime”

                        1. 5

                          It’s been that for me (well, I started using it in my early 20s).

                        2. 2

                          I saw Xi while scrolling down the google github page and my first thought was “What, Another editor? Why do we need that?” After watching this video I’m kinda excited about it. Coolest part in my opinion is the JSON api for plugins. Currently I use atom which can get pretty heavy on ram so I’ll have to check xi out!

                          1. 1

                            Hi @raph, thank you for this enlightening talk and the wonderful work you (and other contributors) have put into Xi. I am a little confused about xi-mac. From your talk, it seems like the xi-mac front-end is pretty independent of the Xi core. The xi-mac GitHub page says that it uses CoreText, but from your talk it seems like you had to work around CoreText and implement your own text rendering that is fast enough, is that correct?

                            If xi-mac is not just a wrapper for CoreText, would it be possible to have xi-mac (or some subset of it) forked off into a general-purpose text rendering system? I think something like that could make for a very useful re-usable component that could be used for multiple editors, terminals, document creation platforms etc.

                            1. 1

                              We should update the readme. It still uses CoreText for shaping, but not for painting pixels.

                              I can imagine splitting off the TextPane into a separate module, depending on whether other applications would find it useful. Certainly it would be possible to use it for a terminal, but alacritty exists and iTerm2 has a new Metal renderer, so I’m not sure who exactly would use it.

                              1. 1

                                Wouldn’t such a component be useful for anything that draws large amounts of text? RSS or PDF readers, Email clients, Markdown previewers, WYSIWYG document editors?

                            2. 1

                              glad to be watching this. Thinking about applying for a week at recurse as I like their mission.