Consider using crates.io/crates/xrl?

[wendivoid]

Hey Raph,
I've been working on xrl trying to get it ready to start working on my front end over the next couple of months, but i'd like to see Xrl used by as many front ends as possible, at least the one's written in rust. I found in my early experience's with Xi writing the Update logic to be a bit tedious and error prone. Xrl handle's all of that logic(or it will after my PR is accepted) just requiring the user to pass a 'Update' to there line cache and Xrl handle's it appropriately. Multiple front ends using xrl would reduce duplication of work throughout the Xi community.

It is already in use by little-dude/xi-tui and i plan on having my front end bytebuddha/Zen running by the end of this year(cant work on it until then, I've got a busy couple of months ), so i'm looking for smaller project's in the Xi ecosystem to work on in my free time.

I chose to try and convert xi-win first because:
- It is small
- Not much development going on at the moment
- It's written in rust
- As far as i know Xrl has never been tested on any OS other than Linux and i would prefer to get testing on both Mac & Windows.

So with that in mind a have a few question's:

• What do you think of using Xrl as a common library for xi front ends
  - If not why?
• Is xi-win in to early a stage to switch to using xrl?
• Have you ever thought about a seperate(or internal in the xi repo?) library to handle all of xi-core front end protocol? (from a front ends point of view)
  - If you have could you share your thoughts on it?

Thank you so much for creating Xi, I've found it to be the perfect project to play with in my free time and has taught me alot!

[raphlinus]

Thanks for the kind words. I haven't had a chance to dig deeply into xrl yet (juggling way too many things at the moment), but let me share some thoughts off the top of my head.

I am in favor of moving rpc to a tokio based system throughout the ecosystem, including both the core and Rust front-ends. From what I've seen, xrl seems like a reasonable base for this, but I haven't dug into it in detail. If it's an official part of xi, it would make sense for the crate to be inside the xi-editor repo, but it doesn't matter all that much. I can also see the scope for a (semi-)official crate to hold the line cache logic, as this is nontrivial to get right.

Right now xi-win is pretty much on hold, but I don't think that blocks changes such as you propose. There's one extremely tricky topic, which I was researching and didn't feel like I fully resolved: how to deal with dxgi swapchain wait objects. Either the drawing should be on the main thread, in which case you need to wait on this object with MsgWaitForMultipleObjectsEx or the like, or the drawing should happen on another thread. It's not clear to me which works better, and it's also not clear to me how well tokio supports these cases.

Zen looks interesting. I think a WebRender based front-end could be interesting for a lot of use cases. If you're not able to work on it yourself (something I can relate to strongly), maybe there's a chance of coordinating contributions by others?

Hope this answers your questions.

[LiHRaM]

@ByteBuddha Development has been picking up a little, and I expect to be contributing rather regularly to xi-win from now on. If you'd like to join us @ zulip, you're more than welcome to. :) There's a budding community there, with representatives from several front-ends.

[wendivoid]

@LiHRaM I signed up, Thanks!