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

221–230 of 306 posts

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

#221

Post by TheAceOfHearts »

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…

Have you tried Terminal.app recently? A lot of people seem to rush immediately to iTerm2... And I used to be one of those, a few years back. But eventually I gave the built-in Terminal.app a serious chance and found it met all my requirements. Although I also stopped customizing my theme, and I keep as many defaults as possible. SF Mono is a great font!

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

#223

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

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

#225

Post by vidarh »

kazinator wrote: post #77
haberman wrote: post #59

Earlier quoted context omitted.

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

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.

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.

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

#226

Post by jzoch »

Derbasti wrote: post #215
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 powerful are you planning your extensions to be? On a scale from Textmate (shortcuts that run shell scripts) to Emacs (you can implement Vim in Emacs), where would Xi's extensions stand?

Considering plugins can be written in any language and communicate via JSON, I'd posit they can be whatever you prefer. Turing-complete, even.

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

#228

Post by alvil »

kazinator wrote: post #77
haberman wrote: post #59

Earlier quoted context omitted.

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

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.

yeah, just another ugly monster with 50 frontends, with stupid name, unusable for the next 50 years. academic shit. :q!

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

#229

Post by vidarh »

raphlinus wrote: post #17
akmittal wrote: post #15

Earlier quoted context omitted.

Is there any particular reason json-rpc was used compared to more performant gRPC?

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…

To second that the serialization format is unlikely to matter: I'm doing my own editor, and I don't put any effort into minimizing deltas, and retransmit more than the full visible window content on every keypress currently. I expected to have to change that to get it fast enough, but latency just isn't noticeable so I've bumped it down to the bottom of my priority list.

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

#230

Post by gt_ »

jstewartmobile wrote: post #79
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.

Off topic, but wonderful job on Inconsolata !

Sorry to prolong the tangent, but that font is truly legendary. A milestone in the human quest for clarity and form, especially if that human is me.
Post reply on HN