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

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

#51

Post by JepZ » Tue, Jan 30, 2018, 8:51 PM UTC

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?

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

#52

Post by sgillen » Tue, Jan 30, 2018, 8:51 PM UTC

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.

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

#53

Post by JepZ » Tue, Jan 30, 2018, 8:54 PM UTC

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.

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

#54

Post by raphlinus » Tue, Jan 30, 2018, 8:55 PM UTC

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?

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

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

#55

Post by evanrelf » Tue, Jan 30, 2018, 9:00 PM UTC

postit wrote: post #25

evanrelf wrote: post #10

Earlier quoted context omitted.

Have you tried using Alacritty? https://github.com/jwilm/alacritty

Have your read my comment? :)

Oops :)

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

#56

Post by JepZ » Tue, Jan 30, 2018, 9:00 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.

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?

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

#57

Post by setr » Tue, Jan 30, 2018, 9:02 PM UTC

agumonkey wrote: post #50

not to be confused with the yi editor https://duckduckgo.com/?q=yi+editor&atb=v59-2__&ia=software

..why a search link install of the homepage of the software?

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

#58

Post by wakkaflokka » Tue, Jan 30, 2018, 9:03 PM UTC

What's the best Windows build for this?

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

#59

Post by haberman » Tue, Jan 30, 2018, 9:06 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.

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

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

#60

Post by willtim » Tue, Jan 30, 2018, 9:06 PM UTC

raphlinus wrote: post #28

willtim wrote: post #26

Earlier quoted context omitted.

A more interesting approach would be to use persistent data structures. While possibly slower for some operations, undo is more efficient and there are really interesting opportunities for concurrency. See: https://github.com/arximboldi/ewig/blob/master/README.md

I believe xi-rope counts as a persistent data structure. We have plug-ins in separate processes now, for isolation, but might explore having them in-process but in separate threads. The underlying data structure should support that just fine. Is there something I'm missing?

A rope data structure is very almost persistent. So perhaps I am splitting hairs! It could of course be made fully persistent if mutating operations are avoided. This would allow sharing them between threads.