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

121–130 of 306 posts

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

#121

Post by raphlinus »

Improvotter wrote: post #100
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?

The xi-gtk frontend is in pretty good shape, but overall the editor is not _quite_ at the point where I'd recommend it for daily use. I don't want to make a promise of a particular date, but I'm hoping fairly soon.

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

#122

Post by vardump »

c-smile wrote: post #112
vardump wrote: post #101

Earlier quoted context omitted.

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

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 DOM elements (like but no margins and only text inside). So we just need to relayout one particular line in order to show typed character.

> For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate).

That's very impressive, if so. On Windows 7 with DWM (GPU display compositor) switched off?

How did you validate and measure latency?

Someone correct me if I'm wrong, but I'm under impression Windows 10 DWM adds additional latency making 16 ms latency unachievable.

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

#123

Post by jarpineh »

gnachman wrote: post #95
eeks wrote: post #18

Earlier quoted context omitted.

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 wo…

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

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

#124

Post by [deleted] »

cortesoft wrote: post #75
keithnz wrote: post #64

Earlier quoted context omitted.

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.

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…

[deleted]

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

#125

Post by amaranth »

brucephillips wrote: post #107
raphlinus wrote: post #91

Earlier quoted context omitted.

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.

> My main goal is to build something that feels entirely like a native app. It's not clear to me how this relates to the question. Emacs and vim are native apps.

They aren't webapps but they're each a different ecosystem and workflow entirely separate from the rest of the OS. You can add integration to various parts of the OS via extra scripts/plugins but that you need to do so proves the point. With Xi it seems the goal is to have a powerful shared core but the UI frontends are tailored for the OS/DE they're meant to be run in rather than having one generic cross-platform frontend.

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

#126

Post by cmyr »

jarpineh wrote: post #113
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.

Latency and multi-process editing environment has been on my radar recently. Programming languages providing analysis servers, external syntax highlighters and of course REPLs all benefit from editor that’s fast and async. Since Jetbrains editors brought zero latency writing to my attention I’ve begun to notice which apps seem to hinder my writing. It’s getting easier to build your own editing system instead of havin…

Xi's medium-range plans for modal editing support[1] are intended to be modular/general enough that you could plug in whatever particular modal-editing implementation you'd like.

1: https://github.com/google/xi-editor/issues/302

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

#127

Post by raphlinus »

JepZ wrote: post #56
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.

What kind of UX model do you have in mind? Something like the vi modes (command, visual, input, etc.), something more GUI like with input mode by default and hotkeys or something completely different?

Definitely the standard modeless text editing model (with multiple cursors though) as the default, and vi-compatible modes as an option. The issue for the latter is linked elsethread.

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

#128

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

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

#129

Post by cmyr »

brucephillips wrote: post #107
raphlinus wrote: post #91

Earlier quoted context omitted.

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.

> My main goal is to build something that feels entirely like a native app. It's not clear to me how this relates to the question. Emacs and vim are native apps.

Maybe we're using different definitions of "native". In the most common case, both of these editors use the cross-platform "VT-100 UI Toolkit" (e.g. ansi escape codes in your terminal emulator), regardless of platform. Some exceptions do exist. But native as it's being used in relation to this project refers specifically to whatever frontend framework is 'the standard' for a given platform, where one exists.

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

#130

Post by brucephillips »

cmyr wrote: post #129
brucephillips wrote: post #107

Earlier quoted context omitted.

> My main goal is to build something that feels entirely like a native app. It's not clear to me how this relates to the question. Emacs and vim are native apps.

Maybe we're using different definitions of "native". In the most common case, both of these editors use the cross-platform "VT-100 UI Toolkit" (e.g. ansi escape codes in your terminal emulator), regardless of platform. Some exceptions do exist. But native as it's being used in relation to this project refers specifically to whatever frontend framework is 'the standard' for a given platform, where one exists.

Ah, I see the miscommunication now. To me, native apps are those that have access to the kernel, as opposed to web apps or bytecode.
Post reply on HN