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

81–90 of 306 posts

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

#81

Post by zawerf »

raphlinus wrote: post #54
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.

Figma (a UI design tool written in C++ compiled to JS using emscripten) talked about this briefly in their tech blog. They compiled FreeType to JS for rendering fonts to bitmaps: https://blog.figma.com/building-a-professional-design-tool-o...

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

#82

Post by avshyz »

kazinator wrote: post #76

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

That's because you (probably) haven't used a modern text editor.

If you'd follow either chrome's or firefox's changelog you'd also read about constant progress in optimizing their browser engine and dev tools.

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

#83

Post by pcwalton »

infogulch wrote: post #62
raphlinus wrote: post #54

Earlier quoted context omitted.

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

That's where pathfinder [1] comes in, as the fastest font rasterizer, utilizing the GPU and built in rust. (not affiliated). Ok maybe I'm overselling just a little but it's exciting! [1]: https://github.com/pcwalton/pathfinder

Thanks for the kind words :) But Pathfinder doesn't do shaping.

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

#84

Post by raphlinus »

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 !

Hey, stay on thread! Thanks for the kind words though.

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

#85

Post by javajosh »

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.

Hi Raph. Do you ever get the feeling that `xi` will inevitably become isomorphic to the "general programming problem" that's been solved many times, at several levels of zoom, distinguished by trade-offs and implementation quality? I mean, what do you do when your general editor implementation inevitably starts feeling like an OS? Or do you think you'll be able to successfully avoid implementing processes, access control, roles, db and/or fs functions etc in your editor, somehow?

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

#86

Post by jstewartmobile »

raphlinus wrote: post #84
jstewartmobile wrote: post #79

Earlier quoted context omitted.

Off topic, but wonderful job on Inconsolata !

Hey, stay on thread! Thanks for the kind words though.

I really like the "loose coupling" JSON-RPC approach. You're doing Alan Kay proud!

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

#87

Post by raphlinus »

steveklabnik wrote: post #65
willtim wrote: post #60

Earlier quoted context omitted.

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.

> This would allow sharing them between threads. This is an area where Rust ends up feeling different than many languages: xi's rope uses https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#metho... like this: https://github.com/google/xi-editor/blob/422948d62688dcc2ee0... , which gives you both options. This code uses Rc, not Arc, so it's not currently sharable between threads, but Arc has the same API. Rust care…

Nope, it's Arc for exactly that reason, though we're not currently using it across threads right now. The fact that it can support immutable semantics safely is one of the really nice features of Rust.

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

#89

Post by casey_lang »

ryanmarsh wrote: post #14

Xi looks great, has a very clever design, and clearly is a next generation platform for building a useful and powerful editor. I'd love to see this project continue and be a success. I think there is plenty of room for yet another text editor. Here's where I'm going to be a bit of a party pooper. Pragmatically speaking all of the great stuff Raph is talking about doesn't really matter. What Raph cares about are the k…

As a long time Atom user I want to agree with you but I'm not sure these editors really have "won".

At least according to HackerRank's "2018 Developer Skills Report"[1] 67% of developers used VIM with only 4% and 2% using VS or Atom.

Stack Overflow in last year's "Developer Survey Results"[2] does align with your opinion however. Sooo... \_(ツ)_/¯

[1] http://research.hackerrank.com/developer-skills/2018/#insigh... [2] https://insights.stackoverflow.com/survey/2017#technology-mo...

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

#90

Post by alkonaut »

mattgreenrocks wrote: post #31
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?

How is it that text editors are all the sudden this weird competition where you have to win? I get what you're saying, but I think you worry too much about social proof and momentum. It's also grossly unfair to Xi, a project in its infancy. As you mentioned earlier, there is room for another great editor. If the same logic had been applied towards the Electron based editors a few years ago, you'd be arguing against t…

I wouldn't call it "winning" but you do need a big piece of the userbase to be relevant (when we are talking about text editors that are 90% plugins and 10% core, like Atom, Sublime, VsCode, Vim, Emacs...)

When I write code in a language I don't find the best language plugin for language X in "my editor". Instead I search for "which editor has the best plugin for language X". And in most of the cases, the difference between different editors is much smaller than the difference in quality between language plugins.

So basically, unless an editor "wins" (say becomes one of the top 5 most used) then there will be very few plugins for that text editor for the next thing that you need a plugin for.

(And let's hope a non-electron editor is the next to gain that momentum.)

Post reply on HN