“I think the Xi model is misguided, I think in a way it is too technology centric.”
As many of other Kakoune users out there, I have a deep relationship with my tools and I particularly enjoy investing time to survey what’s going on in the “text editor” world.
So while my main focus is obviously Kakoune I frequently have a look at cool features provided by other editors (old and new).
When Xi was announced a few years back, I had mix feelings. And today, by reading mawww’s quote above, I’m glad to see that he shares a similar point of view.
On one hand, I really appreciate that so much efforts/design/research was poured into trying to find the perfect data structures to hold a buffer, how to get the best butter smooth experience for beautiful GUIs on different platform. I truly believe that Xi is a fantastic opportunity to explore what Rust can do.
At the same time, while skimming through the docs, the blog posts and the Github issues about Xi, I’m disappointed about how few discussions are geared toward usability, towards the end-user experience about what this editor will do. It’s like that they are building a Formula1 engine, but how the steering wheel and the brakes will work is not (yet) fully envisioned. Almost as is “plugins author will figure these stuffs out”.
So in a way, I feel like Xi is in the “emacs end of the spectrum”. Providing a strong technological platform but without much choices about how the final editor will behave. Meanwhile, I love that Kakoune vision is first about strong text-editing model (operations on multi-selections) without losing the performance side of things at the same time.
I see an opposition between a theorical world vs a practical one.
What’s your opinion on this?
I see Kakoune as next generation Vim, and Xi as next generation Emacs. However, there’s big however. Emacs isn’t just an editor, it’s more. It’s a platform. Xi claims to be editor’s core, while Emacs claims to have kitchen sink. That’s a big deal.
I find it strange. On one hand it seems like a “text editor engine”, as highlighted by their focus on data structures and other internal details. But on the other hand, they talk about beautiful and native UIs, so it’s evidently also aimed at end users. Like you said, there is no mention of anything that happens in-between, such as how the user is supposed to interact with the backend (where are the regex?).
I also don’t find the stated goals very impressive. They look like they’re written in comparison with VScode/Atom where high performance and reliability might be novel, but at the same time I’m pretty sure this has been achieved decades ago by many editors. I’d argue that kakoune achieves all these goals readily (except maybe “beautiful” if you’re not into text UIs (scrollbar when?)).
This might be the fanboy in me speaking, but I think it’s a harder challenge to create a well-designed application focused on editing code than a more generic “bring your own editing model” platform. Would it be possible to recreate kakoune’s editing model using Xi with the same level of performance and reliability? I doubt it.
Vim has ruined me. Once you take modal editing redpill you can never go back. It has become a force of habit now. I frequently see myself typing :w randomly in my bash prompt, online comment boxes and other places. But since modal editor has a steep learning curve, there are not many modal editors. There is only vi and it’s children and Kak (and what else?)
I see a lot of different editors that advertise many new intuitive features like Sublime, VSCode, Atom, Acme and now Xi but I can never use them because modal editing has ruined it for me.
Perhaps that’s not because of learning curve, but because back in old days pretty much all software was modal. But with the development of user interfaces towards simplicity and accessibility, modal approach gone. (n)?Vi(m|s)? are the only survivals. It’s good to see that this approach is kind of reborn with Kakoune, since it isn’t a direct clone of Vi, and it takes bit different approach as well.