Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

recurse.com

Post reply on HN
Print view View original

91–100 of 306 posts

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

#91

Post by raphlinus »

gradstudent wrote: post #78
raphlinus wrote: post #11

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.

Can you please comment on Xi as a general editor and specifically in relation to vim and Emacs, arguably the two best general editors from the last few decades. Thanks!

I don't want to knock either, they're both obviously great editors. My main goal is to build something that feels entirely like a native app. Also, I'm hoping that the async model for plug-ins will preserve responsiveness even when there are a lot of plug-ins and they do nontrivial work.

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

#93

Post by tomjakubowski »

eeks wrote: post #18
postit wrote: post #9

Xi creator did an amazing work implementing ropes ( https://github.com/google/xi-editor/tree/master/rust/rope ) The design documents ( 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 b…

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…

Have you tested iTerm2's Metal renderer performance with the integrated Intel GPU?

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

#94

Post by jjrh »

sgillen wrote: post #52
myrandomcomment wrote: post #47

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.

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.

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.

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

#95

Post by gnachman »

eeks wrote: post #18
postit wrote: post #9

Xi creator did an amazing work implementing ropes ( https://github.com/google/xi-editor/tree/master/rust/rope ) The design documents ( 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 b…

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…

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.

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

#97

Post by raphlinus »

haberman wrote: post #59
raphlinus wrote: post #11

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.

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

Not specifically, but I did dig deep into the state syncing literature in general, both Operational Transforms and CRDT's. The problem we're trying to solve is a bit different than mosh, because we don't need to compensate for network latency in particular; RPC should be very fast.

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

#98

Post by 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)... 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

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 for each "string" in MS Visual Code), see: 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... (sciter on DirectX) and sciter.dll nearby. Download https://github.com/c-smile/sciter-sdk/blob/master/samples/%2... and open it with the sciter-dx.exe.

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

#99

Post by raphlinus »

Numberwang wrote: post #69
raphlinus wrote: post #11

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.

How far away are you from a cross platform 'product'?

At the rate we're going, it will be a while. It takes time, and I'm trying to get the right answers rather than racing toward shipping. It's a very different environment than a product-focused startup, and I'm happy about that.

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

#100

Post by Improvotter »

raphlinus wrote: post #11

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.

Great talk, I've been eyeing Xi for a bit now and am really looking forward to giving it a shot. Is there any window for when this can actually be put to use on Linux/Mac? I've had a look at the frontends, but they're not very active and they're pretty bare so far. Any idea when these will be more substantial?
Post reply on HN