
Xi: an editor for the next 20 years [video] - davidbalbert
https://www.recurse.com/events/localhost-raph-levien
======
postit
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_sci...](https://github.com/google/xi-
editor/tree/master/doc/rope_science)) 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.

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

~~~
gnachman
iTerm2's design is saddled by some history. At the time I took it over,
everything was done in a single thread. By the time I realized I was going to
stay with the project and how bad the design was, it was too late to change
it. I've moved as much work as possible off the main thread (parsing the
bytestream and now rendering). I think Terminal gets very nice performance
without resorting to Metal by doing only UI work on the main thread. I think
the Metal renderer will prove to be worthwhile, even though it was a lot of
work to create that could've been avoided (kinda) if the design had been fixed
8 years ago.

As for using CPU when idle, there was a bug where a background thread was
doing the equivalent of running `ps` over and over. That's been fixed in the
last few versions, but please file issues for such things and I'll get to them
as soon as I'm able.

~~~
jarpineh
I'll add my thank you. I'm also backer at Patreon.

With tmux control mode it's already very good and now with faster rendering
coming...

~~~
acoard
I've got an unrelated question about tmux/iTerm2 - hope you don't mind me
asking.

I'm a heavy iTerm2 user and always been curious about tmux. Is there any
reason to try out tmux integration if I'm already comfortable with iTerm2's
features and panelling? I kind of got the impression tmux integration was
largely for people who love tmux and are migrating to iTerm2, so it just makes
it more familiar. Or is it something I should take another look at?

~~~
hultner
I’d say it’s the opposite as an die hard tmux-user. I don’t really use the
integration since I’m more comfortable with my terminal in full screen and my
own tmux config. The integration services seems more appropriate for someone
who doesn’t already have their tmux-bindings and workflow stamped into muscle
memory but rather just want the benefits of detaching their terminal sessions
from their terminal application while retaining iterm native tabs, windows and
panes.

I’ve tried out the integration mode a few times but it just doesn’t fit my
workflow (often switching sessions, highly customized tmux configuration,
etc).

~~~
Myrmornis
Exactly. For people who already use tmux heavily, and use it on linux as well
as macos, the iterm2 integration isn’t going to be an attractive direction.
Partly because it will lose the uniform experience across OSs, and partly
because they’re happy with session/window/pane management using tmux’s UI.

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

~~~
haberman
For the protocol between core and front-end, did you take any inspiration from
mosh's state sync protocol? [https://mosh.org/mosh-paper-
draft.pdf](https://mosh.org/mosh-paper-draft.pdf)

~~~
kazinator
Text editors shouldn't have a "core" and "front end" and "protocol".

Monolithic machine executable that fits into under a meg of RAM and comes up
in a fraction of a second from a cold invocation.

~~~
vidarh
Yes, they should. And here is why:

1\. Stability. I'm writing my own editor at the moment, and the text buffers
are kept in a server process. Last time I updated the server process it'd been
running continuously for a month despite extensive reworking of the frontend.
The backed is trivially simple (~300 lines), and easy to keep stable. If the
frontend crashes it doesn't take my open buffers with it.

2\. Coming up in a fraction of a second _with state_ most of the time. Most of
the time I have a ton of buffers _in RAM_ ; rather than reloading a ton of
files, most of the time when I bring up the frontend, the files I'm working on
are already there. Re-establishing an IPC connection to the backend is not
noticeable.

3\. Faster starts over slow network connections - I can run the backend
remotely and not have to transfer a big file other than what is needed to view
the bits I care about.

4\. Simplicity: I don't need to implement tabs or multiple windows - I got
that for free from my window manager. Instead if I want to split the current
buffer, I just spawn a new frontend that re-attaches to the same buffer from
another process. There should be no need for an editor to re-implement its own
window management.

A client-server design makes very little difference to memory usage and
doesn't require a separate executable.

~~~
michaelmrose
Even as part of the minority that use window managers on linux I find the idea
of merely using the window manager exclusively in place of other forms of UI
for multiple documents/pages/buffers within a gui app as fantastically
underwhelming.

Lets look at firefox as an example. The fact that a vertical tabbar is more
useful in this case due to screen shape and size and it being useful to be
able to read a bit more of the text when you have a lot of tabs. This could in
theory by done by your wm even though I've not seen one that does. Further
tree style tabs shows a visual hierarchy of sorts that can't be replicated by
your wm because it doesn't know what link was opened from what. Further you
can perform operations on groups of tabs, like closing them, bookmarking them,
reloading them. Its difficult to see how your wm could infer this hierarchy
and how it could allow application specific operations like bookmarking even
if it could. Further its useful to sometimes open a number of links in the
background before switching to any of the above. This is trivially effected
within the browser but challenging outside of it because the action of opening
a link happens inside the browser.

Within my irc client various channels are arranged according to network and
color coded according to activity. Right clicking on individual channels or
networks allows specific actions regarding those networks or channels. None of
the above would work with a bunch of stacked/tabbed windows.

I could make a list for emacs but the complaint is the same wm ends up being
an unfixably poorer alternative to dealing with multiple documents in the app.

I use i3wm not because its awesome at managing multiple documents but because
its simple and straightforward and 90% of workspaces, which span only a single
monitor, have only 1-2 windows on them. Rarely 3 or 4 and never more.

Window managers are just unfixably mediocre in this respect because the UI
doesn't have access to context and can't differ based on use.

~~~
vidarh
I neither use a vertical tab-bar or tree style tabs, so maybe I'd think
otherwise if I did. But if so, I'd rather see that as an argument to improve
on window management (and yes, it'd require new APIs) rather than an argument
for making applications continue to implement their own tabs. But for me
that's not relevant, and one of the nice things about being able to fully
control the structure of my own editor is not having to worry about use-cases
like that.

When it comes to emacs, I don't agree - the multi-window support I added to my
editor was something I added explicitly to mimic my Emacs usage with i3wm.
It's very possible that it's down to how I use emacs - I tend to prefer to
split with ^X+2 and ^X+3, and that pattern lends itself perfectly to doing
window splits with a window manager. If anything, i3wm's support for tabs
etc., selectively for any window, is more advanced than the buffer/frame
management emacs offers.

> Window managers are just unfixably mediocre in this respect because the UI
> doesn't have access to context and can't differ based on use.

That's just not the case when you 1) have the source, and 2) are able to
control the wm via an API that can provide additional context. To be clear: My
current support for this is 100% tied to i3wm, and relies on i3-msg to let me
choose which orientation to do the split and exec another instance, and my
needs in that respect are simple.

It would be harder to get the same flexibility with a wm that lacks an equally
trivial API to control placement. Again, a benefit of being able to fully
control my own editor (I am slowly packaging up less opinionated parts of it
as separate projects - my goal is that "my" personal part of the editor should
be reduced to nothing more than instantiating various generic components) -
because of the client-server approach, the grand total of my "multi window
support" boils down to this ("term" in this case is a local alias for whatever
my current preferred terminal is) :

    
    
        182│     def split_vertical◂
        183│        system("i3-msg 'split vertical; exec term e --buffer #{@buffer.buffer_id}'")◂  
        184│     end◂
        185│
        186│     def split_horizontal◂
        187│        system("i3-msg 'split horizontal; exec term e --buffer #{@buffer.buffer_id}'")◂
        188│     end◂

------
c-smile
"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/sci...](https://github.com/c-smile/sciter-
sdk/blob/master/bin/32/sciter-dx.exe) (sciter on DirectX) and sciter.dll
nearby. Download [https://github.com/c-smile/sciter-
sdk/blob/master/samples/%2...](https://github.com/c-smile/sciter-
sdk/blob/master/samples/%2Bcolororizer/show-master-css.htm) and open it with
the sciter-dx.exe.

~~~
raphlinus
I'll have to try this out. My experiments indicated that DirectWrite could not
keep up with drawing on a 4k monitor at 60 Hz, though was ok at a smaller
window. I think it might depend a lot on driver too. I'll see if I can
instrument the xi-win prototype to give performance numbers. I do note that
your lines aren't very wide, but still, in my tests I wasn't seeing anything
like 500fps. DirectWrite does at least seem to use the GPU, while Core Text
appears to rely entirely on software rendering.

Skia is definitely capable of good performance, as it resolves down to OpenGL
draw calls, pretty much the same as Alacritty, WebRender, and now xi-mac. One
thing though is that it doesn't do fully gamma-corrected alpha compositing, so
it's not anywhere near pixel-accurate to CoreText rendering.

Doing proper measurement is not easy, but seems worth doing.

~~~
jwilm
> Skia is definitely capable of good performance, as it resolves down to
> OpenGL draw calls, pretty much the same as Alacritty, WebRender, and now xi-
> mac.

This claim is a bit surprising to me. I was under the impression Skia is an
immediate mode renderer which ends up issuing a lot GL calls that could be
avoided with a retained mode renderer.

~~~
kllrnohj
An immediate-style API does not mean the work is performed immediately. Skia
defers and reorders internally to batch commands so minimal GL state changes
are required.

That said a "lot of GL calls" for a 2D UI is actually a trivially
insignificant number of GL calls to the actual GPU/driver for most cases.
That's basically never the bottleneck unless you've done something insanely
wrong.

~~~
IshKebab
I wouldn't be so sure. A single draw call is surprisingly slow. If you drew
each glyph with one draw call that could be hundreds which will definitely
cause slowness.

~~~
kllrnohj
"hundreds" is actually what I meant by insignificant to a modern driver.

For example:
[https://images.anandtech.com/graphs/graph11223/86100.png](https://images.anandtech.com/graphs/graph11223/86100.png)

Granted that's a 1060 but since we're looking at driver CPU overhead that
shouldn't matter much. So 2.3 million draw calls per second in DX11 single
threaded.

It's not until you start getting into the 10k+ draw calls a frame that you are
putting your 60fps at risk.

It's often worth the work to avoid this anyway, after all faster is better if
you're an engine/renderer, but it takes a lot for it to be an actual _problem_

~~~
IshKebab
Yeah, so 2 million, cut that down by 10 for integrated graphics. Then you need
60 fps, that brings it down to 3000. If you're _just_ doing empty draw calls
and nothing else. Throw in WebGL and hundreds is really significant.

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

~~~
weinzierl
> 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
Recent article: [https://danluu.com/input-lag/](https://danluu.com/input-lag/)

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

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

~~~
cortesoft
I am guessing he works at a place that has a lot of servers that he connects
to, and he wants to be able to use his editor on whatever server he is on.

I know this is an issue where I work. We have 40 thousand plus servers, and we
aren't going to have everyone install their editor of choice on all those
machines. If I have an issue I need to check on a server that requires some
text editing, I have to use one of the default editors.

~~~
frou_dh
This is the appeal of sshfs - to be able to easily mount remote filesystems
and use local tools against them.

~~~
erk__
One of the best tools I have used with something like this is emacs's tramp-
mode. It just works when you connect to another host.

------
xyproto
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
We have plenty of editors to choose from but we might use a Editor which has
VSCode/Atom features+customization and vim performance.

~~~
sametmax
Sublime text is quite close to that.

~~~
IshKebab
It's not open source though.

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

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

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

------
kranzky
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
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
Oh. Well, damn. I guess Steve Yegge was right. Anyway, wouldn't it be great if
Google launched a kick-ass text editor?

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

~~~
raphlinus
"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
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)

~~~
pcwalton
Thanks for the kind words :) But Pathfinder doesn't do shaping.

~~~
infogulch
Ah, thanks for the clarification. It seems I need to do a bit more research
before I advocate others projects, sorry about that. :)

------
valarauca1
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
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))

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

~~~
Retr0spectrum
Almost every English word that starts with an X has a "z" sound. e.g. xenon,
xylophone, xiphoid. In fact, I can't think of any exceptions.

"zigh" as a pronunciation seems natural to me.

~~~
dhimes
Yeah, but when you ask a Chinese person how to pronounce Xi or Xiu the X ->
sh. That's why I went with Shee also when I read this.

~~~
mixmastamyk
Portuguese also.

------
netgusto
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)

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

------
adultSwim
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!

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

------
anotheryou
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)

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

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

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

------
rwx------
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
From a quick glance you should probably cd into the rust/ subdirectory to
build the rust code of this project.

------
wakkaflokka
What's the best Windows build for this?

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

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

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

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

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

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

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

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

~~~
mailslot
IntelliJ is still slow even when I throw 12 cores Xeons at it.

... aside from the fact that I can compile some projects faster than it takes
just to start up.

If IntelliJ were a car, it'd be gas guzzling SUV with a hole in the gas tank.

~~~
icedchai
If you think IntelliJ is bad, what do you think of Eclipse?

One of my worst IDE experiences was working on a Scala project in Eclipse,
with a whole ton of plugins installed. Latency was incredibly high. It was
like working on a lagged 300 baud terminal.

------
agumonkey
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
..why a search link install of the homepage of the software?

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

~~~
coldtea
> _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_

Unfortunately that's not true. If only MORE people that build text editors
actually DID geek out on such things. Alas, we have 30+ years of editors that
got all those wrong.

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

Well, they don't win with me. But even if so, I don't see why you can't have
an optimal platform AND a big ecosystem. Or how json-rpc (which is what the
plugins will need to talk to) is a high "barrier to entry".

~~~
z3t4
if the editor is slow its certnly not due to core. but most likely that its
parsing 10k files for intellisense. even the most naive implementation of a
text editor will be fast.

