Xi: an editor for the next 20 years [video] • Hacker News Board

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

#71

Post by kakarot » Tue, Jan 30, 2018, 9:23 PM UTC

EddieRingle wrote: post #5

vardump wrote: post #2

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.

You might be interested in this article from a JetBrains developer who implemented zero-latency typing in IDEA: https://pavelfatin.com/typing-with-pleasure/

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.

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

#72

Post by remram » Tue, Jan 30, 2018, 9:24 PM UTC

jacobparker wrote: post #63

raphlinus wrote: post #17

Earlier quoted context omitted.

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…

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

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.

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

#73

Post by [deleted] » Tue, Jan 30, 2018, 9:27 PM UTC

coldtea wrote: post #39

ryanmarsh wrote: post #22

Earlier quoted context omitted.

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?

> Based upon momentum I believe the Electron based ecosystem has already won, yes. Based upon momentum Nicky Minaj is better than John Coltrane. So there's that.

[deleted]

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

#74

Post by electricslpnsld » Tue, Jan 30, 2018, 9:29 PM UTC

JepZ wrote: post #53

JepZ wrote: post #51

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?

Just found https://github.com/acheronfail/xi-electron but actually I was more thinking of running the whole editor in the browser, not just the frontend.

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/

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

#75

Post by cortesoft » Tue, Jan 30, 2018, 9:32 PM UTC

keithnz wrote: post #64

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.

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

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

#76

Post by kazinator » Tue, Jan 30, 2018, 9:33 PM UTC

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

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

#77

Post by kazinator » Tue, Jan 30, 2018, 9:34 PM UTC

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

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.

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

#78

Post by gradstudent » Tue, Jan 30, 2018, 9:43 PM UTC

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!

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

#79

Post by jstewartmobile » Tue, Jan 30, 2018, 9:44 PM UTC

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!

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

#80

Post by pohl » Tue, Jan 30, 2018, 9:45 PM UTC

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.

I remember listening to your talk about Xi at RustConf '16, and being amazed at how deeply you've been thinking about text editors. This talk is a nice update on your thoughts.

How soon do you think it will be before more product-level thinking can be brought into the mix?

(Edit: I see I'm not the only one to ask a question along these lines.)