11–20 of 162 posts
Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
It's saying one thing that you're asking for it when the article explicitly says he believes this was a mistake from the beginning.
I remember looking at one of Raph's early presentations and being both convinced by his arguments for and impressed with the design decisions made, the same ones he outlines here. After doing some of my own comparatively rudimentary research, coming to similar conclusions as he did. It left me very excited to watch the project develop over time.
One thing I was wondering about is that the Xi website contains a list of front ends similar to the list in the GitHub repo, but includes a Flutter implementation for Fuchsia[1] that is now a dead link and missing from the GitHub list. He mentions it briefly in this retrospective as well. Any ideas what happened to it?
Earlier quoted context omitted.
Atom already seems to have gone somewhat towards maintenance mode since Microsoft bought Github. Feels like there's a lot less by way of features being released and a lot more just keeping up with ecosystem/OS changes. I could certainly be wrong though.
Atom competes pretty directly against VS Code doesn't it? It makes sense that Microsoft would consolidate their efforts.
Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
I believe Onivim is in this camp. I don't know how well that's working out for them, or whether there are any others.
I'd looked at Xi about a year ago when I was finally running out of patience with Atom's terrible performance, but the lack of a workable Windows solution pushed me to VSCode in the end.
I've been watching/rooting for Xi from a distance for a few years now. This is an excellent retrospective. Well written, but also very honest, especially about those all too typical project highs and lows. I remember looking at one of Raph's early presentations and being both convinced by his arguments for and impressed with the design decisions made, the same ones he outlines here. After doing some of my own compara…
Aww, this is really disappointing to hear but an excellent read nonetheless. I always had Xi in the corner of my eye as a very interesting way to make a text editor that had a lot of good things going for it: modularity, native UI, speed…I think if it worked out it would have been really great. It's really sad to hear that it didn't. Thank you, Raph and the rest of the Xi contributors, for working on it for all these…
I agree with you that getting shortcuts (and other similar aspects) right is more important than which code is used to implement text editing. We're very much going to try to take that to heart as we implement more text capabilities in Druid.
Regarding LSP. Yes, while the functionality is there, it is very difficult to implement a really polished user experience with it. I think a lot of that is in the design of the protocol itself; it's hard to avoid annotating the wrong region when there are concurrent edits. It's interesting to think about how to do better, but I fear you'd be bringing in a lot of complexity, especially if you started doing some form of Operational Transformation. I would highly recommend that if someone were to take this on, they study xi in detail, both for what it got right and what was difficult.
Earlier quoted context omitted.
It's saying one thing that you're asking for it when the article explicitly says he believes this was a mistake from the beginning.
That’s fine. I don’t completely agree with his analysis. Just because he couldn’t make it work doesn’t mean someone else can’t.
had that feeling... as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. that paradigm or at least the way we implement it might even mean more trouble than a synchronous counterpart. also, other editors that i feel will be sunset or not worked on at some point are atom and brackets.
What are your thoughts on this topic @raphlinus ?