10 ms·

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

750 points by davidbalbert 9y ago

vardump 9y ago
There finally starts to be consciousness about input and output latency for GUI applications. Xi sounds like an editor I'd love to use. Latency while typing is a jarring experience.
- EddieRingle 9y ago
  You might be interested in this article from a JetBrains developer who implemented zero-latency typing in IDEA: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
  - kakarot 9y ago
    I first switched to Webstorm in early 2016, on a Windows laptop at the time, and the latency was absolutely horrific. I'm talking 100-800ms. I was so off-put, even after changing a few settings, that I returned to Notepad++ for a while. I'd never been so disgusted at a piece of software. It's the 21st century and we're dealing with input latency in a text editor??? Eventually they seemed to fix things and it started running better, and now on Linux it runs buttery smooth and is a joy to use, but clearly they were not finished with their work by the time this article was published.
    - rplnt 9y ago
      I bought (though in a sale) PyCharm few years back, without trying it much before (my bad), and found it really really bad. Used maybe 12 hours of my one year license. Somehow got accustomed to to pretty much vanilla Sublime, mostly because I can't seem to get the language "intelligence" plugins to work correctly.
      - kakarot 9y ago
        You should give PyCharm another go. If you don't have a license anymore, JetBrains offers a free community version. It is more than enough to suit my needs. What did you find bad about it? If it was just input latency, that's fixed.
        rplnt 9y ago
        The UI overall was slow (I wouldn't remember if input delay was part of it). It's been in 2012 or 2013 I think, so yeah, I would hope they got better at it :)
- kyrra 9y ago
  Xi backend repo: https://github.com/google/xi-editor https://github.com/google/xi-editor Fuschia front-end client for Xi: https://fuchsia.googlesource.com/topaz/+/master/app/xi/ https://fuchsia.googlesource.com/topaz/+/master/app/xi/
  - cmyr 9y ago
    The official frontend is a Cocoa/Swift app: https://github.com/google/xi-mac https://github.com/google/xi-mac
    - pjmlp 9y ago
      > Native UI. Cross-platform UI toolkits never look and feel quite right. The best technology for building a UI is the native framework of the platform. On Mac, that’s Cocoa. Thumbs up!
- taeric 9y ago
  People used to put a lot of effort into minimizing latencies. In large because they had to. However, you almost always land in an effectively cooperatively multitasking environment if you want truly lightning fast latency. Just after that, you are just reimplmenting schedulers and other preemptive tools. All of which just gives a hot target to a few particularly scheduled jobs that every developer feels their stuff has to happen in.
- weinzierl 9y ago
  > Latency while typing is a jarring experience. This is so true. I grew up on the Commodore 64. The machine was usually pretty responsive, but when I typed too quickly in my word processor it sometimes got stuck and ate a few characters. I used to think: "If computers were only fast enough so I could type without interruption...". If you'd asked me back then for a top ten list what I wished computers could do, this would certainly have been on the list. Now, 30 years later, whenever my cursor gets stuck I like to think: "If computers were only fast enough so I could type without interruption..."
  - mixmastamyk 9y ago
    Recent article: https://danluu.com/input-lag/ https://danluu.com/input-lag/
valarauca1 9y ago
I'm glad `xi` is separating the editor core from the UI. 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.
- juancampa 9y ago
  NeoVim is moving towards this goal too. If you are a vimmer you should keep an eye on Oni (https://github.com/onivim/oni https://github.com/onivim/oni)
bnolsen 9y ago
VI(m) has been around for a long time now....
- msla 9y ago
  Indeed, and so has Emacs, in various forms (TECO, pure Lisp, and the modern C-and-Elisp version people use now).
ozten 9y ago
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's probably worth it to maintain performance.
- cryptonector 9y ago
  I agree. Async is critical. It's very important to catch the need for async early on, and then implement as async from the get-go. Going from sync to async is pretty much a rewrite, and no fun at all.
postit 9y ago
Xi creator did an amazing work implementing ropes (https://github.com/google/xi-editor/tree/master/rust/rope https://github.com/google/xi-editor/tree/master/rust/rope) The design documents (https://github.com/google/xi-editor/tree/master/doc/rope_science https://github.com/google/xi-editor/tree/master/doc/rope_sci...) explaining the concepts and implementation details is a must for those who want to understand its core. 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't even have time to blink with my current setup. 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.
- evanrelf 9y ago
  Have you tried using Alacritty? https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty
  - postit 9y ago
    Have your read my comment? :)
    - evanrelf 9y ago
      Oops :)
- eeks 9y ago
  I must concur. With an equivalent vim setup and code files, nothing beats X11/suckless terminal on my OpenBSD machine. Comparing to that, even Alacritty looks like a slug. I must say however that things are looking a bit better in iTerm2 when switching the Metal renderer on. It's just a shame that an Nvidia GPU on OSX is necessary to compete with my $1000 Lenovo with its crappy Intel chip on OpenBSD when it comes to text editing latency.
  - 9y ago
raphlinus 9y ago
Presenter here, feel free to ask questions. Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.
- akmittal 9y ago
  Is there any particular reason json-rpc was used compared to more performant gRPC?
  - raphlinus 9y ago
    Universal out-of-the-box support in almost every language. The actual performance impact is subtle - for most core/front-end interactions, the messages are very small (because we put so much effort into minimizing the deltas). It's also the case that there are ridiculously fast JSON implementations out there. We did discover that Swift's is not one of them though. I have a prototype of a faster one using Codable; I'd consider upstreaming it to Swift but just need to find the time. I'd consider a different serialization format, but it doesn't seem to be on the critical path for either performance or functionality, so I feel there are a lot of other things ahead of it.
    - jacobparker 9y ago
      Theoretically you could use gRPC with JSON or Flatbuffers or whatever rather than protobufs. (I'm not sure how much practice there is behind that theory, currently, but that's the plan.)
      - remram 9y ago
        gRPC is not necessarily the magical tool everyone would like to believe. It is mostly developed by Google with a lot of magic in it. For instance, in Python using gRPC is totally incompatible with multiprocessing (meaning: it will crash both processes) and has been for a year (1.4.0...1.8.4), because of all the C logic (and multiple threads) running behind it. I for one am glad they didn't go towards custom protocols with single complex implementations, towards something that can be assembled easily from standard components.
ryanmarsh 9y ago
Xi looks great, has a very clever design, and clearly is a next generation platform for building a useful and powerful editor. I'd love to see this project continue and be a success. I think there is plenty of room for yet another text editor. Here's where I'm going to be a bit of a party pooper. Pragmatically speaking all of the great stuff Raph is talking about doesn'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's all great. 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. I'm rarely impressed by software projects (close or open) and I'm even less often impressed by Microsoft but what they'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. I'm not saying I don't want Xi to continue to grow and be as great as it can be, I'm just being pragmatic.
- jblow 9y ago
  You named some random things that have been around for short periods of time and claimed that "they won". I don't get it.
  - ryanmarsh 9y ago
    Based upon momentum I believe the Electron based ecosystem has already won, yes. The momentum there eclipses... Eclipse, as well as many other closed and open source editors. If you don't see the Electron ecosystem as a winner today would you say they'll have won if all editors stay at their current momentum of new features and bug fixes?
    - ovao 9y ago
      I think it’s fair enough to say that, from the perspective of community momentum and extension momentum, they’ve “won”, sure. It’s also fair to say that in many cases a user’s text editor doesn’t need quite that breadth of extensibility and/or feature-richness, and that winning that war (or battle) isn’t really all that important to at least some subset of users. That’s where Xi fits. It’s saying “these things we don’t get from other editors are important”. Users are free to decide which feature or attributes are most important to them. At the end of the day, users win!
pnathan 9y ago
> Separation into front-end and back-end modules. That solves a lot of the Emacs trouble iiuc. (Same for the Async first design). > The xi editor will communicate with plugins through pipes, letting them be written in any language, That's caused a lot of trouble for vi/vim, has it not? I get the separation of concerns, but intermingling the concerns has helped emacs in a certain way.
- eadmund 9y ago
  > > Separation into front-end and back-end modules. > That solves a lot of the Emacs trouble iiuc. True enough. Despite the fact that it's IMNSHO the best editor out there, emacs is not without its problems. It has a lot of historical baggage. > I get the separation of concerns, but intermingling the concerns has helped emacs in a certain way. I agree. One of the huge features of emacs is that (above a very low level) everything is implemented in a fairly decent Lisp, and everything is available to Lisp code. How much will plugins be able to dig into one anothers' internals in order to get work done? Yes, monkey-patching is bad — but it's better than not being able to monkey-patch. Relying on plugin authors to expose extension points is probably not going to work in the long run: it really helps being able to define advice on functions, wrap functions, replace functions, mutate internal variables when one knows what one's doing &c.
myrandomcomment 9y ago
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. 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.
- sgillen 9y ago
  Even emacs is not installed by default on most operating systems. Even worse a lot of people customize their emacs setup so much that using the default setting can be painful.
  - jjrh 9y ago
    A emacs-tiny would be nice. Emacs package is just too large to be a default. On servers I usually just install mg/zile/jed.
    - eadmund 9y ago
      > On servers I usually just install mg/zile/jed. I normally just use TRAMP. For those who've not used it, it's an incredible little emacs package which gives one a very Plan-9-esque feeling, in the sense that all the different systems one connects to feel like one whole. As an example, when one is editing a remote file shell-command runs commands on the remote system, and of course find-file and friends work exactly like normal — only looking at files on the remote system.
  - lorenzhs 9y ago
    I use tramp-mode to connect to remote systems, which provides comfortable editing without requiring anything other than ssh access to the target machine. It’s quite nice.
- keithnz 9y ago
  What's your reasoning behind needing it to be a default install? seems an odd requirement for an editor. For instance, notepad is default on windows, and I'll use that when needed on vanilla windows machines, but for the 99% of my editor needs I install and customize a number of enviroments (including Vim). I don't mind whether it's installed by default or not.
agumonkey 9y ago
not to be confused with the yi editor https://duckduckgo.com/?q=yi+editor&atb=v59-2__&ia=software https://duckduckgo.com/?q=yi+editor&atb=v59-2__&ia=software
- setr 9y ago
  ..why a search link install of the homepage of the software?
JepZ 9y ago
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. 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?
- JepZ 9y ago
  Just found https://github.com/acheronfail/xi-electron https://github.com/acheronfail/xi-electron but actually I was more thinking of running the whole editor in the browser, not just the frontend.
  - electricslpnsld 9y ago
    Do any of the latency advantages of Xi carry over if you wrap it all up in Electron? The Electron editors do pretty badly on this front [1]. [1] https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
    - raphlinus 9y ago
      I haven't started measuring it yet, but plan to. The idea of keeping the UI component light and doing all the heavy lifting in the core _might_ work well in Electron (as opposed to having all the logic in JS), and xi-electron is a good testbed for exploring that.
- raphlinus 9y ago
  "Easy" is not the right word for this, but it's possible. One challenge is that browsers don't export an interface for "shaping". For Latin script, that means kerning and ligatures, and for complex scripts, it means being able to render it correctly at all. Currently, alacritty doesn't really deal with this, but xi-mac does, using the interfaces provided by Core Text.
  - infogulch 9y ago
    That's where pathfinder [1] comes in, as the fastest font rasterizer, utilizing the GPU and built in rust. (not affiliated). Ok maybe I'm overselling just a little but it's exciting! [1]: https://github.com/pcwalton/pathfinder https://github.com/pcwalton/pathfinder
wakkaflokka 9y ago
What's the best Windows build for this?
- MisterTea 9y ago
  It's somewhere in /dev/null.
- davidbalbert 9y ago
  I believe it will eventually live at https://github.com/google/xi-win https://github.com/google/xi-win, though I think the focus is on getting the Mac version working first.
  - raphlinus 9y ago
    Indeed. I was hoping to put more effort into xi-win than it's gotten, but for a variety of reasons have decided to focus on the macOS front end for now, as there's quite a bit of work remaining to get a daily-usable editor up on one platform.
kazinator 9y ago
> modern text editor with uncompromising performance Solution in search of a problem. I haven't run into an editor performance issue in more than twenty years. I will gladly trade a hundred text editor performance fixes for one web browser performance fix.
- avshyz 9y ago
  That's because you (probably) haven't used a modern text editor. If you'd follow either chrome's or firefox's changelog you'd also read about constant progress in optimizing their browser engine and dev tools.
  - brucephillips 9y ago
    > That's because you (probably) haven't used a modern text editor. Can you provide an example? Because I've worked on > 1MM line projects in IntelliJ with no performance issues, or at least none related to text editing.
    - cmrdporcupine 9y ago
      Holy crap, try bringing the Chromium codebase into CLion. UI freezes up constantly while the C++ indexing engine does... stuff. Then eventually hangs untill SIGKILLed. Even after giving the JVM 48 gigs on my 64gig dual Xeon 36 core workstation. Which is a great argument for Xi's architectural choice to disentangle syntax highlighting and display out into separate processes.
    - jacoblambda 9y ago
      A lot of people refer to atom and vscode when complaining about the performance of modern text editors and while they are not the only modern text editors by far, they are definitely some of the more popular ones at the moment. I can definitely say that atom has performance issues. I get lockups and stutters working on small and medium sized files (hundreds to thousands of lines) and it is infuriating. It is unfortunate because there are a lot of great new plugins for these platforms but they consistently cause me all kinds of trouble. Old school editors(like vim or emacs) or modern IDEs perform much better as text editors nowadays compared to plain modern text editors.
netgusto 9y ago
Comment of the author of iterm2 on HN, about latency optimization: https://news.ycombinator.com/item?id=14800195 https://news.ycombinator.com/item?id=14800195
anotheryou 9y ago
Super cool! I hope you find someone to unfuck the WYSIWYG UX. (I'm hoping your markdown will be both, markdown and WYSI-nearly-WYG)
c-smile 9y ago
"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter (https://sciter.com https://sciter.com)... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen text rendering on DirectX surface using Direct2D/DirectWrite primitives. Display is 192 ppi - 3840x2160: https://sciter.com/temp/plain-text-syntax.png https://sciter.com/temp/plain-text-syntax.png 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 "game event loop" style. In reality (render on demand as in sciter.exe) CPU consumption is 3% on kinetic scroll (120 FPS). As you see platform text rendering is quite capable of drawing texts on modern hardware. As of problems of text layouts ... Not that CPU and memory consuming too to be honest. Sciter uses custom ::mark(name) pseudo-elements that allow to style arbitrary text runs/ranges without the need of creating artificial DOM elements (like <span> for each "string" in MS Visual Code), see: https://sciter.com/tokenizer-mark-syntax-colorizer/ https://sciter.com/tokenizer-mark-syntax-colorizer/ To try this by yourself: get https://github.com/c-smile/sciter-sdk/blob/master/bin/32/sciter-dx.exe https://github.com/c-smile/sciter-sdk/blob/master/bin/32/sci... (sciter on DirectX) and sciter.dll nearby. Download https://github.com/c-smile/sciter-sdk/blob/master/samples/%2Bcolororizer/show-master-css.htm https://github.com/c-smile/sciter-sdk/blob/master/samples/%2... and open it with the sciter-dx.exe.
- vardump 9y ago
  > On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. Sure, 500 fps, but that's not the important part. Latency would be. So at 500 fps with how much output latency to the display?
  - c-smile 9y ago
    For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate). Editor keeps each line in separate <text> DOM elements (like <p> but no margins and only text inside). So we just need to relayout one particular line in order to show typed character.
bedros 9y ago
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's what I like about sublime, I can install it in home directory without needing admin help. would you support plugins in a scripting language like python?
pier25 9y ago
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. Edit: So I built Xi-Mac and the file opens in a fraction vs ST3 but once it's open performance is just as bad or maybe even worse.
- patrickaljord 9y ago
  A 15MB json file is more like a mini database, it'd be faster to run a quick script to import it in a nosql json database and then query from there. It may take 5 minutes but then you won't want to throw yourself out of the window when trying to edit/query it.
  - cmyr 9y ago
    There's no technical reason you shouldn't be able to happily scroll through (and edit) a 15MB json file; and search for an arbitrary string should take ~10ms (ballpark from playing around with ripgrep just now), certainly not slow enough to merit big up front indexing costs.
  - inferiorhuman 9y ago
    Why? jq should be able to make quick work out of it, or Postgres if you need more complex queries.
  - tootie 9y ago
    I could open a 15mb file in Eclipse 10 years ago. Idk why we're reinventing the wheel when we have flying cars. If you're not just using a JetBrains editor then you're being a masochist.
- cmyr 9y ago
  Is this a debug build or a release build? File loading isn't particularly fast atm (we load the whole file into memory) but once a file is open I can breeze through it..
  - pier25 9y ago
trisimix 9y ago
You should change your video in my opinion. Especially the intro part it kinda made me roll my eyes.
kranzky 9y ago
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't get it approved as a 20% project.
- yla92 9y ago
  It is not "coming" from Google despite it is under Google GitHub organization. There is a disclaimer[1] at the bottom of the repo README, stating that "This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.". It's my understanding that it's Raph code and Google has nothing to do with it other than having to own the code. [1] : https://github.com/google/xi-editor#disclaimer https://github.com/google/xi-editor#disclaimer
  - kranzky 9y ago
    Oh. Well, damn. I guess Steve Yegge was right. Anyway, wouldn't it be great if Google launched a kick-ass text editor?
bch 9y ago
I sure did like the core<—>core communicating idea for multiple users of a single document. It seemed like an easy trap to imagine X11 as the f/e, b/e, plugins, async were talked about, but not “just” using a remote f/e to communicate w a remote core was sort of enlightening (having fell into the X11 trap as the talk was progressing). 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?
johnklos 9y ago
Nice ideas, but it's a shame that Rust is barely portable.
- sinistersnare 9y ago
  How is it barely portable? Sure, less than C for now, but its not 'barely.'
rcdwealth 9y ago
Emacs: an editor for last 20 years and next 20 years.
xyproto 9y ago
I'm so conflicted about this. On one hand, having the "engine" 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's one type of open source applications we have enough to choose from already, it's editors. If it's for fun and the educational process, then by all means, that's swell. Bui if it's because the world needs yet another editor, just because it can be written in Rust, I'm not so sure.
- akmittal 9y ago
  We have plenty of editors to choose from but we might use a Editor which has VSCode/Atom features+customization and vim performance.
  - sametmax 9y ago
    Sublime text is quite close to that.
    - IshKebab 9y ago
      It's not open source though.
- dsego 9y ago
  Probably none of them got it quite right then. There are people who want a lightweight but extendable GUI editor. The fact that people, including me, pay for Sublime Text, when there are powerful open-source alternatives around, kinda proves that there is a demand for such a thing.
rwx------ 9y ago
Trying to build it, but I get error: could not find `Cargo.toml` in `/home/xyz/Downloads/xi-editor-0.2.0` or any parent directory
- Lev1a 9y ago
  From a quick glance you should probably cd into the rust/ subdirectory to build the rust code of this project.
erikb 9y ago
Never I would have guessed that "xi" is pronounces "gsai". I would pronounce it "shee" (like chinese) or "ksai" (english) or "ksee" (german). Also, I don't thin we need another editor with a pluggable focus. It'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 "open file", "read file", "write file" and "close file" with the other tools. It basically _IS_ the plugin for editing files. And if you really want an editor containing plugins, then there'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.
- RandomCSGeek 9y ago
  They say it's pronounced "Zigh". I am a non-native English speaker, so I am not even going to try to question this.
  - erikb 9y ago
    Thanks. However "z" is also not really a clear sound, right? "ds" or "ssss" or "tsss". Naturally I would interpret "zigh" very similar to "sigh" but since "sigh" is a real thing I think there is a reason why you write "zigh" instead. Anyway each hint is helpful. I'll google for that.
    - NoahTheDuke 9y ago
      To help out, let me point you to the English phonology page on wikipedia: https://en.wikipedia.org/wiki/English_phonology https://en.wikipedia.org/wiki/English_phonology . Specifically, look into the 'Voiced alveolar sibilant', the 'z' in English. That's the sound you're looking for, as it's the one used by Raph in the linked talk. For completeness, the vowel is the dipthong 'aɪ', pronounced like the 'i' in the word 'price', discussed on the same wiki page.
      - erikb 9y ago
        Great resource, thanks a lot! I think this is really the stuff you can't learn in high school education and have to learn by yourself. There our teachers are native Germans as well and while they are probably better than the average second language English learner they can't be perfect either. In Chinese the "x" would be pronounced like that: https://en.wikipedia.org/wiki/Voiceless_alveolo-palatal_fricative https://en.wikipedia.org/wiki/Voiceless_alveolo-palatal_fric... So not really a "sh-" either, but English doesn't have that sound at all I believe.
usermac 9y ago
I wonder if the name is a tip of the hat to China and their leader. Anyone know?
nkagan 9y ago
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.
adultSwim 9y ago
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. Text editors running on the desktop that are based on web browsers was a big step backwards. It encouraged features/plugins but now my text editor and my chat client each take gigabytes to run!
mobilemidget 9y ago
Tried it, xi-mac, though trips over a minimised font awesome css here, not even with all fonts, locks/freeze all other open windows.

750 points by davidbalbert 9y ago

There finally starts to be consciousness about input and output latency for GUI applications. Xi sounds like an editor I'd love to use. Latency while typing is a jarring experience.

EddieRingle 9y ago
You might be interested in this article from a JetBrains developer who implemented zero-latency typing in IDEA: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
- kakarot 9y ago
  I first switched to Webstorm in early 2016, on a Windows laptop at the time, and the latency was absolutely horrific. I'm talking 100-800ms. I was so off-put, even after changing a few settings, that I returned to Notepad++ for a while. I'd never been so disgusted at a piece of software. It's the 21st century and we're dealing with input latency in a text editor??? Eventually they seemed to fix things and it started running better, and now on Linux it runs buttery smooth and is a joy to use, but clearly they were not finished with their work by the time this article was published.
  - rplnt 9y ago
    I bought (though in a sale) PyCharm few years back, without trying it much before (my bad), and found it really really bad. Used maybe 12 hours of my one year license. Somehow got accustomed to to pretty much vanilla Sublime, mostly because I can't seem to get the language "intelligence" plugins to work correctly.
    - kakarot 9y ago
      You should give PyCharm another go. If you don't have a license anymore, JetBrains offers a free community version. It is more than enough to suit my needs. What did you find bad about it? If it was just input latency, that's fixed.
      - rplnt 9y ago
        The UI overall was slow (I wouldn't remember if input delay was part of it). It's been in 2012 or 2013 I think, so yeah, I would hope they got better at it :)
kyrra 9y ago
Xi backend repo: https://github.com/google/xi-editor https://github.com/google/xi-editor Fuschia front-end client for Xi: https://fuchsia.googlesource.com/topaz/+/master/app/xi/ https://fuchsia.googlesource.com/topaz/+/master/app/xi/
- cmyr 9y ago
  The official frontend is a Cocoa/Swift app: https://github.com/google/xi-mac https://github.com/google/xi-mac
  - pjmlp 9y ago
    > Native UI. Cross-platform UI toolkits never look and feel quite right. The best technology for building a UI is the native framework of the platform. On Mac, that’s Cocoa. Thumbs up!
taeric 9y ago
People used to put a lot of effort into minimizing latencies. In large because they had to. However, you almost always land in an effectively cooperatively multitasking environment if you want truly lightning fast latency. Just after that, you are just reimplmenting schedulers and other preemptive tools. All of which just gives a hot target to a few particularly scheduled jobs that every developer feels their stuff has to happen in.
weinzierl 9y ago
> Latency while typing is a jarring experience. This is so true. I grew up on the Commodore 64. The machine was usually pretty responsive, but when I typed too quickly in my word processor it sometimes got stuck and ate a few characters. I used to think: "If computers were only fast enough so I could type without interruption...". If you'd asked me back then for a top ten list what I wished computers could do, this would certainly have been on the list. Now, 30 years later, whenever my cursor gets stuck I like to think: "If computers were only fast enough so I could type without interruption..."
- mixmastamyk 9y ago
  Recent article: https://danluu.com/input-lag/ https://danluu.com/input-lag/

valarauca1 9y ago

I'm glad `xi` is separating the editor core from the UI. 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.

juancampa 9y ago
NeoVim is moving towards this goal too. If you are a vimmer you should keep an eye on Oni (https://github.com/onivim/oni https://github.com/onivim/oni)

bnolsen 9y ago

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

msla 9y ago
Indeed, and so has Emacs, in various forms (TECO, pure Lisp, and the modern C-and-Elisp version people use now).

ozten 9y ago

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's probably worth it to maintain performance.

cryptonector 9y ago
I agree. Async is critical. It's very important to catch the need for async early on, and then implement as async from the get-go. Going from sync to async is pretty much a rewrite, and no fun at all.

postit 9y ago

Xi creator did an amazing work implementing ropes (https://github.com/google/xi-editor/tree/master/rust/rope https://github.com/google/xi-editor/tree/master/rust/rope) The design documents (https://github.com/google/xi-editor/tree/master/doc/rope_science https://github.com/google/xi-editor/tree/master/doc/rope_sci...) explaining the concepts and implementation details is a must for those who want to understand its core. 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't even have time to blink with my current setup. 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.

evanrelf 9y ago
Have you tried using Alacritty? https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty
- postit 9y ago
  Have your read my comment? :)
  - evanrelf 9y ago
    Oops :)
eeks 9y ago
I must concur. With an equivalent vim setup and code files, nothing beats X11/suckless terminal on my OpenBSD machine. Comparing to that, even Alacritty looks like a slug. I must say however that things are looking a bit better in iTerm2 when switching the Metal renderer on. It's just a shame that an Nvidia GPU on OSX is necessary to compete with my $1000 Lenovo with its crappy Intel chip on OpenBSD when it comes to text editing latency.
- 9y ago

raphlinus 9y ago

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

akmittal 9y ago
Is there any particular reason json-rpc was used compared to more performant gRPC?
- raphlinus 9y ago
  Universal out-of-the-box support in almost every language. The actual performance impact is subtle - for most core/front-end interactions, the messages are very small (because we put so much effort into minimizing the deltas). It's also the case that there are ridiculously fast JSON implementations out there. We did discover that Swift's is not one of them though. I have a prototype of a faster one using Codable; I'd consider upstreaming it to Swift but just need to find the time. I'd consider a different serialization format, but it doesn't seem to be on the critical path for either performance or functionality, so I feel there are a lot of other things ahead of it.
  - jacobparker 9y ago
    Theoretically you could use gRPC with JSON or Flatbuffers or whatever rather than protobufs. (I'm not sure how much practice there is behind that theory, currently, but that's the plan.)
    - remram 9y ago
      gRPC is not necessarily the magical tool everyone would like to believe. It is mostly developed by Google with a lot of magic in it. For instance, in Python using gRPC is totally incompatible with multiprocessing (meaning: it will crash both processes) and has been for a year (1.4.0...1.8.4), because of all the C logic (and multiple threads) running behind it. I for one am glad they didn't go towards custom protocols with single complex implementations, towards something that can be assembled easily from standard components.

ryanmarsh 9y ago

Xi looks great, has a very clever design, and clearly is a next generation platform for building a useful and powerful editor. I'd love to see this project continue and be a success. I think there is plenty of room for yet another text editor. Here's where I'm going to be a bit of a party pooper. Pragmatically speaking all of the great stuff Raph is talking about doesn'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's all great. 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. I'm rarely impressed by software projects (close or open) and I'm even less often impressed by Microsoft but what they'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. I'm not saying I don't want Xi to continue to grow and be as great as it can be, I'm just being pragmatic.

jblow 9y ago
You named some random things that have been around for short periods of time and claimed that "they won". I don't get it.
- ryanmarsh 9y ago
  Based upon momentum I believe the Electron based ecosystem has already won, yes. The momentum there eclipses... Eclipse, as well as many other closed and open source editors. If you don't see the Electron ecosystem as a winner today would you say they'll have won if all editors stay at their current momentum of new features and bug fixes?
  - ovao 9y ago
    I think it’s fair enough to say that, from the perspective of community momentum and extension momentum, they’ve “won”, sure. It’s also fair to say that in many cases a user’s text editor doesn’t need quite that breadth of extensibility and/or feature-richness, and that winning that war (or battle) isn’t really all that important to at least some subset of users. That’s where Xi fits. It’s saying “these things we don’t get from other editors are important”. Users are free to decide which feature or attributes are most important to them. At the end of the day, users win!

pnathan 9y ago

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

eadmund 9y ago
> > Separation into front-end and back-end modules. > That solves a lot of the Emacs trouble iiuc. True enough. Despite the fact that it's IMNSHO the best editor out there, emacs is not without its problems. It has a lot of historical baggage. > I get the separation of concerns, but intermingling the concerns has helped emacs in a certain way. I agree. One of the huge features of emacs is that (above a very low level) everything is implemented in a fairly decent Lisp, and everything is available to Lisp code. How much will plugins be able to dig into one anothers' internals in order to get work done? Yes, monkey-patching is bad — but it's better than not being able to monkey-patch. Relying on plugin authors to expose extension points is probably not going to work in the long run: it really helps being able to define advice on functions, wrap functions, replace functions, mutate internal variables when one knows what one's doing &c.

myrandomcomment 9y ago

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. 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.

sgillen 9y ago
Even emacs is not installed by default on most operating systems. Even worse a lot of people customize their emacs setup so much that using the default setting can be painful.
- jjrh 9y ago
  A emacs-tiny would be nice. Emacs package is just too large to be a default. On servers I usually just install mg/zile/jed.
  - eadmund 9y ago
    > On servers I usually just install mg/zile/jed. I normally just use TRAMP. For those who've not used it, it's an incredible little emacs package which gives one a very Plan-9-esque feeling, in the sense that all the different systems one connects to feel like one whole. As an example, when one is editing a remote file shell-command runs commands on the remote system, and of course find-file and friends work exactly like normal — only looking at files on the remote system.
- lorenzhs 9y ago
  I use tramp-mode to connect to remote systems, which provides comfortable editing without requiring anything other than ssh access to the target machine. It’s quite nice.
keithnz 9y ago
What's your reasoning behind needing it to be a default install? seems an odd requirement for an editor. For instance, notepad is default on windows, and I'll use that when needed on vanilla windows machines, but for the 99% of my editor needs I install and customize a number of enviroments (including Vim). I don't mind whether it's installed by default or not.

agumonkey 9y ago

not to be confused with the yi editor https://duckduckgo.com/?q=yi+editor&atb=v59-2__&ia=software https://duckduckgo.com/?q=yi+editor&atb=v59-2__&ia=software

setr 9y ago
..why a search link install of the homepage of the software?

JepZ 9y ago

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. 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?

JepZ 9y ago
Just found https://github.com/acheronfail/xi-electron https://github.com/acheronfail/xi-electron but actually I was more thinking of running the whole editor in the browser, not just the frontend.
- electricslpnsld 9y ago
  Do any of the latency advantages of Xi carry over if you wrap it all up in Electron? The Electron editors do pretty badly on this front [1]. [1] https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
  - raphlinus 9y ago
    I haven't started measuring it yet, but plan to. The idea of keeping the UI component light and doing all the heavy lifting in the core _might_ work well in Electron (as opposed to having all the logic in JS), and xi-electron is a good testbed for exploring that.
raphlinus 9y ago
"Easy" is not the right word for this, but it's possible. One challenge is that browsers don't export an interface for "shaping". For Latin script, that means kerning and ligatures, and for complex scripts, it means being able to render it correctly at all. Currently, alacritty doesn't really deal with this, but xi-mac does, using the interfaces provided by Core Text.
- infogulch 9y ago
  That's where pathfinder [1] comes in, as the fastest font rasterizer, utilizing the GPU and built in rust. (not affiliated). Ok maybe I'm overselling just a little but it's exciting! [1]: https://github.com/pcwalton/pathfinder https://github.com/pcwalton/pathfinder

wakkaflokka 9y ago

What's the best Windows build for this?

MisterTea 9y ago
It's somewhere in /dev/null.
davidbalbert 9y ago
I believe it will eventually live at https://github.com/google/xi-win https://github.com/google/xi-win, though I think the focus is on getting the Mac version working first.
- raphlinus 9y ago
  Indeed. I was hoping to put more effort into xi-win than it's gotten, but for a variety of reasons have decided to focus on the macOS front end for now, as there's quite a bit of work remaining to get a daily-usable editor up on one platform.

kazinator 9y ago

> modern text editor with uncompromising performance Solution in search of a problem. I haven't run into an editor performance issue in more than twenty years. I will gladly trade a hundred text editor performance fixes for one web browser performance fix.

avshyz 9y ago
That's because you (probably) haven't used a modern text editor. If you'd follow either chrome's or firefox's changelog you'd also read about constant progress in optimizing their browser engine and dev tools.
- brucephillips 9y ago
  > That's because you (probably) haven't used a modern text editor. Can you provide an example? Because I've worked on > 1MM line projects in IntelliJ with no performance issues, or at least none related to text editing.
  - cmrdporcupine 9y ago
    Holy crap, try bringing the Chromium codebase into CLion. UI freezes up constantly while the C++ indexing engine does... stuff. Then eventually hangs untill SIGKILLed. Even after giving the JVM 48 gigs on my 64gig dual Xeon 36 core workstation. Which is a great argument for Xi's architectural choice to disentangle syntax highlighting and display out into separate processes.
  - jacoblambda 9y ago
    A lot of people refer to atom and vscode when complaining about the performance of modern text editors and while they are not the only modern text editors by far, they are definitely some of the more popular ones at the moment. I can definitely say that atom has performance issues. I get lockups and stutters working on small and medium sized files (hundreds to thousands of lines) and it is infuriating. It is unfortunate because there are a lot of great new plugins for these platforms but they consistently cause me all kinds of trouble. Old school editors(like vim or emacs) or modern IDEs perform much better as text editors nowadays compared to plain modern text editors.

netgusto 9y ago

Comment of the author of iterm2 on HN, about latency optimization: https://news.ycombinator.com/item?id=14800195 https://news.ycombinator.com/item?id=14800195

anotheryou 9y ago

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

c-smile 9y ago

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

vardump 9y ago
> On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. Sure, 500 fps, but that's not the important part. Latency would be. So at 500 fps with how much output latency to the display?
- c-smile 9y ago
  For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate). Editor keeps each line in separate <text> DOM elements (like <p> but no margins and only text inside). So we just need to relayout one particular line in order to show typed character.

bedros 9y ago

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's what I like about sublime, I can install it in home directory without needing admin help. would you support plugins in a scripting language like python?

pier25 9y ago

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. Edit: So I built Xi-Mac and the file opens in a fraction vs ST3 but once it's open performance is just as bad or maybe even worse.

patrickaljord 9y ago
A 15MB json file is more like a mini database, it'd be faster to run a quick script to import it in a nosql json database and then query from there. It may take 5 minutes but then you won't want to throw yourself out of the window when trying to edit/query it.
- cmyr 9y ago
  There's no technical reason you shouldn't be able to happily scroll through (and edit) a 15MB json file; and search for an arbitrary string should take ~10ms (ballpark from playing around with ripgrep just now), certainly not slow enough to merit big up front indexing costs.
- inferiorhuman 9y ago
  Why? jq should be able to make quick work out of it, or Postgres if you need more complex queries.
- tootie 9y ago
  I could open a 15mb file in Eclipse 10 years ago. Idk why we're reinventing the wheel when we have flying cars. If you're not just using a JetBrains editor then you're being a masochist.
cmyr 9y ago
Is this a debug build or a release build? File loading isn't particularly fast atm (we load the whole file into memory) but once a file is open I can breeze through it..
- pier25 9y ago

trisimix 9y ago

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

kranzky 9y ago

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't get it approved as a 20% project.

yla92 9y ago
It is not "coming" from Google despite it is under Google GitHub organization. There is a disclaimer[1] at the bottom of the repo README, stating that "This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.". It's my understanding that it's Raph code and Google has nothing to do with it other than having to own the code. [1] : https://github.com/google/xi-editor#disclaimer https://github.com/google/xi-editor#disclaimer
- kranzky 9y ago
  Oh. Well, damn. I guess Steve Yegge was right. Anyway, wouldn't it be great if Google launched a kick-ass text editor?

bch 9y ago

I sure did like the core<—>core communicating idea for multiple users of a single document. It seemed like an easy trap to imagine X11 as the f/e, b/e, plugins, async were talked about, but not “just” using a remote f/e to communicate w a remote core was sort of enlightening (having fell into the X11 trap as the talk was progressing). 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?

johnklos 9y ago

Nice ideas, but it's a shame that Rust is barely portable.

sinistersnare 9y ago
How is it barely portable? Sure, less than C for now, but its not 'barely.'

rcdwealth 9y ago

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

xyproto 9y ago

I'm so conflicted about this. On one hand, having the "engine" 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's one type of open source applications we have enough to choose from already, it's editors. If it's for fun and the educational process, then by all means, that's swell. Bui if it's because the world needs yet another editor, just because it can be written in Rust, I'm not so sure.

akmittal 9y ago
We have plenty of editors to choose from but we might use a Editor which has VSCode/Atom features+customization and vim performance.
- sametmax 9y ago
  Sublime text is quite close to that.
  - IshKebab 9y ago
    It's not open source though.
dsego 9y ago
Probably none of them got it quite right then. There are people who want a lightweight but extendable GUI editor. The fact that people, including me, pay for Sublime Text, when there are powerful open-source alternatives around, kinda proves that there is a demand for such a thing.

rwx------ 9y ago

Trying to build it, but I get error: could not find `Cargo.toml` in `/home/xyz/Downloads/xi-editor-0.2.0` or any parent directory

Lev1a 9y ago
From a quick glance you should probably cd into the rust/ subdirectory to build the rust code of this project.

erikb 9y ago

Never I would have guessed that "xi" is pronounces "gsai". I would pronounce it "shee" (like chinese) or "ksai" (english) or "ksee" (german). Also, I don't thin we need another editor with a pluggable focus. It'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 "open file", "read file", "write file" and "close file" with the other tools. It basically _IS_ the plugin for editing files. And if you really want an editor containing plugins, then there'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.

RandomCSGeek 9y ago
They say it's pronounced "Zigh". I am a non-native English speaker, so I am not even going to try to question this.
- erikb 9y ago
  Thanks. However "z" is also not really a clear sound, right? "ds" or "ssss" or "tsss". Naturally I would interpret "zigh" very similar to "sigh" but since "sigh" is a real thing I think there is a reason why you write "zigh" instead. Anyway each hint is helpful. I'll google for that.
  - NoahTheDuke 9y ago
    To help out, let me point you to the English phonology page on wikipedia: https://en.wikipedia.org/wiki/English_phonology https://en.wikipedia.org/wiki/English_phonology . Specifically, look into the 'Voiced alveolar sibilant', the 'z' in English. That's the sound you're looking for, as it's the one used by Raph in the linked talk. For completeness, the vowel is the dipthong 'aɪ', pronounced like the 'i' in the word 'price', discussed on the same wiki page.
    - erikb 9y ago
      Great resource, thanks a lot! I think this is really the stuff you can't learn in high school education and have to learn by yourself. There our teachers are native Germans as well and while they are probably better than the average second language English learner they can't be perfect either. In Chinese the "x" would be pronounced like that: https://en.wikipedia.org/wiki/Voiceless_alveolo-palatal_fricative https://en.wikipedia.org/wiki/Voiceless_alveolo-palatal_fric... So not really a "sh-" either, but English doesn't have that sound at all I believe.

usermac 9y ago

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

nkagan 9y ago

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.

adultSwim 9y ago

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. Text editors running on the desktop that are based on web browsers was a big step backwards. It encouraged features/plugins but now my text editor and my chat client each take gigabytes to run!

mobilemidget 9y ago

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