91–100 of 162 posts
This was solving problems nobody really has, so its fate was predictable. Here's what I think could take off like a rocket: a VSCode-like experience that runs completely in terminal, and therefore does not require a "remote" of any kind. Better yet if it takes most of the same plugins, to reuse the immense amount of work people have done there (and are not going to re-do for some hotshot new editor). Note how none of…
Earlier quoted context omitted.
I think the point being made is that it is required for fast text rendering.
Still feels like that should not be the case. What changed so heavily in the last decade? 2d rendering used to be hella fast without the gpu. Right?
Once upon a time (a decade ago) it was OK for apps to directly draw to the front window, compositing wasn't a super established thing. This saves on precious memory bandwidth, which CPUs didn't really get all that much more of over the last decade.
However now that GPU composition has to happen, GPUs actually don't super like the linear formats that CPUs write to. They want swizzled textures, and they keep those formats private. And on not-heterogeneous memory systems, the buffer the CPU writes into needs to be sent over to the GPU as well.
Meanwhile screen resolutions & pixel counts skyrocket, as did UI visual & animation expectations. Being responsive is a lot easier than being fluid. Especially if you're trying to be fluid on a high-resolution and/or high-refresh rate display.
And this is all while ignoring things like Apple's "high DPI" handling, which is to just say fuck it and downscale instead. Which means you're pushing resolutions far higher than the display's actual resolution quite commonly.
Earlier quoted context omitted.
Still feels like that should not be the case. What changed so heavily in the last decade? 2d rendering used to be hella fast without the gpu. Right?
Screen resolution / 4k monitors? And maybe font complexity (i.e. lots of web pages seem to be downloading fonts now)
Resolution could also matter, but we did have higher resolution displays back in the day, as well. Feels like 2d acceleration somehow regressed.
Earlier quoted context omitted.
Still feels like that should not be the case. What changed so heavily in the last decade? 2d rendering used to be hella fast without the gpu. Right?
Rendering models & expectations changed. Once upon a time (a decade ago) it was OK for apps to directly draw to the front window, compositing wasn't a super established thing. This saves on precious memory bandwidth, which CPUs didn't really get all that much more of over the last decade. However now that GPU composition has to happen, GPUs actually don't super like the linear formats that CPUs write to. They want sw…
Even sending the buffer to the gpu for compositing makes sense as a problem, but still feels that should be faster than you would care about in a text editor.
I'm also on a mac that, if I do something that is "gpu accelerated", I'm likely to get a frozen session. Such that most applications don't seem to need gpu help. Are they just using different parts of it?
Earlier quoted context omitted.
The accessibility APIs can be programmed against by anyone. If there is a way to make something like this accessible to screen readers in some useful way, it would likely involve specific accessibility work either way.
> If there is a way to make something like this accessible to screen readers in some useful way If by "something like this" you mean a text editor, then there's no question; they can be made accessible with a screen reader, and some complex ones (e.g. Visual Studio Code, Visual Studio, and Xcode) are accessible already. > it would likely involve specific accessibility work either way. For the main UI of a full-featur…
If you are developing a text editor, you should put the time into your text editor. It's the thing that distinguishes you from your competitors. And it's the part that users interact with the most. Your users are likely to ask for features, like vi keybindings, that you can't easily build with the OS-native text field anyway.
Incidental forms, like your preferences screen? Unless you have a lot of time and money to burn, the OS widgets will probably be better than yours.
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've run into that phenomenon a lot with various startup projects over the years. It's soul crushing, and often an immediate reaction is to assume certain projects are direct competition, rendering your project fruitless.
In retrospect, this ends up almost never being the case. In a way, you become your own worst enemy. The correct solution is to simply ignore it and press on, but this is certainly easier said than done—especially when morale is already low, and without the benefit of hindsight.
>Perhaps more important, because these projects are more ambitious than one person could really take on, the community started around xi-editor is evolving into one that can sustain GUI in Rust.
In the end, I still think that counts as a success. Perhaps it will prove to be an even greater success than the original goal.
Thanks for all these write-ups, they're excellent. Like other commenters, I've been watching at a distance for years now. Your work is much appreciated.
On the github page https://github.com/xi-editor/xi-editor : JSON. The protocol for front-end / back-end communication, as well as between the back-end and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction for developing plug-ins, as it’s available out of the box for most modern la…
Yes. In this discussion and on Reddit, people still talk about binary vs textual as the source of the problem, but I've argued (based on empirical data) that the lexical details are not the reason for the performance problems. Also, Swift is marketed as a fast language (also based on LLVM), yet in my measurements it's 20x to 50x slower than Rust for JSON processing. I found that surprising. Would you not?
JSON's parsing performance is difficult, whether or not the language doing the parsing is fast or not. There's a reason that there are almost always libraries claiming faster JSON performance, regardless of the language.
Go is marketed as a fast language, and they're still trying to build a high performance JSON parser [0].
Parsing JSON will always be slower than most of the alternatives.
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.
> 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...
See https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...
It's mostly due to their build system.