Xi-Editor Retrospective
raphlinus.github.io
Xi-Editor Retrospective
1–10 of 162 posts
Re: Xi-Editor Retrospective
#2had 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.
Re: Xi-Editor Retrospective
#3had 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.
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.
Re: Xi-Editor Retrospective
#4had 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.
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.
Microsoft probably wants people to use vscode.
Re: Xi-Editor Retrospective
#5had 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.
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.
Re: Xi-Editor Retrospective
#6Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
Re: Xi-Editor Retrospective
#7Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
I think perhaps libvim is like that? https://github.com/onivim/libvim
Re: Xi-Editor Retrospective
#8Is 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.
Re: Xi-Editor Retrospective
#9Aww, 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 years; even if it didn't upend the text editor market I am appreciative of the effort and the lessons you've learned along the way.
Some other side conversations I've had about this that might be interesting and relevant:
* Native UI is not always the right choice. That might seem surprising coming from someone who pushes native UI extremely strongly in general, and I don't want to be misunderstood as recommending you choose something else for your next project (if you have to ask: don't). But in some very specific contexts, such as performant text editing/rendering, it can be problematic to use a high-level control. In fact, many of the text views I use in are not using the standard platform controls but a custom view doing its own drawing: Terminal.app does its own thing (it doesn't even use NSScrollView!), Xcode has the Pegasus editor written in Swift, iTerm draws text using Metal, and Sublime Text is Skia. Platform controls are meant for 99% of apps that don't need absolute control over performance or text rendering, and sometimes you can push them quite far. But in some cases it's appropriate to abandon them. (I will note that all of the examples handle actual text editing very, very well. If you don't know what the standard shortcuts for editing text are for my platform, you're not going to do it right.)
* I love that LSP exists and that it makes my "dumb" editor "smart". But having worked with it a bit, I think it might suffer from some of the same problems: it uses a client-server architecture and JSON to communicate, which means it is not all that performant and needs to keep track of asynchronous state in a coherent way. And not just the state of one document, but the states of many documents, all in different contexts and workspaces, all with their own compiler flags and completion contexts and cursor locations–it is really hard to do this correctly and quickly, although many language servers do an admirably good job. Perhaps it's just "good enough" that it's here to stay, or maybe it has enough support that it can have some of its issues wrinkled out with time.
Re: Xi-Editor Retrospective
#10had 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.
> as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea.
This is why libvim (from the oni2 project) is based on vim rather than neovim. Even aside from performance, it is a huge simplification if you can interact with an editor engine in the same process, synchronously. At some point we replaced simple function calls with baroque APIs accessed over localhost...