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

61–70 of 306 posts

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

#61

Post by __jal »

XR0CSWV3h3kZWg wrote: post #49
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…

Yeah iterm2 is pretty unacceptable. For me alacritty is still missing some polish (i.e. text size keeps on changing when I attached/detach monitors), but it's really solid for using nvim. I've actually been using nvim as my terminal multiplexer instead of using tmux.

iTerm2 with the new renderer is awesome. Even without it on a slow old mac, you can tune it to behave normally. One thing I found in the past was that particular fonts would slow it down a lot - never bothered to hunt down what was going on, but I think the author was/is doing something a little odd there.

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

#62

Post by infogulch »

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.

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

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

#63

Post by jacobparker »

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…

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

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

#64

Post by keithnz »

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.

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

#65

Post by steveklabnik »

willtim wrote: post #60
raphlinus wrote: post #28

Earlier quoted context omitted.

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.

> 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 cares about sharing more than immutability.

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

#66

Post by ericfrederich »

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, good talk. I was wondering if you could elaborate more on your JSON RPC mechanism and the use of threads vs. processes. Coming from the Python world I could see it very hard or impossible to use one plugin written in Python2 and another written in Python3 within the same process.

I have successfully integrated several interpreters/event loops into the same process (C++/Boost, Python, Tcl/Tk, Qt). It was a real pain to implement and felt very hacky but worked.

Using processes you can achieve something like a micro-service architecture. An example of where I've seen this kind of coupling is the custom transfer agents in Git LFS.

https://github.com/git-lfs/git-lfs/blob/master/docs/custom-t...

They use processes and line delimited JSON for communication.

Post reply on HN