Item — HN Reader

To some extent, the architecture of xi-editor was inspired by similar thoughts - not escape codes, but updates to the UI specified as JSON-RPC, and with one process handling the nitty-gritty of UI, the other (in Rust, but conceptually language agnostic, in fact Go was under serious consideration) specifying the application logic. The original implementation only stood up an editor, but making that rich enough to support a full IDE experience could conceptually support other GUI applications. I wasn't particularly familiar with MGR, but the Blit[1] had somewhat a somewhat similar flavor and was definitely on my radar. We even considered the possibility of running the protocol over the network, because at heart it's just byte streams (and already somewhat optimized, as the idea was to use intelligent diffing to minimize the work needed to be done by the UI process).

It didn't work out. It turns out to be very complex to support modern UI, and making it async upped the complexity even more. I'm not saying this couldn't be done, but these days I'm much more interested in UI architectures where everything is in process and more tightly coupled.

[1]: https://en.wikipedia.org/wiki/Blit_(computer_terminal)

1 comments

Have you written up why it didn't work out? Was it mostly the async-is-a-complexity-multiplier stuff you described in https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...? Your mention of "modern UI" makes me think there's more to the story.

I've been thinking of writing more. Doing real text layout is one of the tricky bits, and one that terminals sidestep because layout calculations are trivial as long as you narrow scope down to grids of monospaced ASCII characters.

I'd be very interested in reading it! I've been thinking about the problem of performant real text layout a lot lately. I'm guessing you're not including optimization-based paragraph filling (like TeX or GNU fmt) in "real text layout"?

I think it's potentially in scope, but optional - there are other problems more urgent to solve, and then with more powerful compute and font technology, it's possible to go past TeX into microtypography (some of which was done in hz, but not really widely adopted). Either way, to do Knuth-Plass paragraph optimization, you need lots of metrics of the words to decide the line breaks, and to do the micro stuff, you need even more fine-grained information from the font. Breaking that across a process boundary is... tricky.

A thing I've been struck by when looking at medieval manuscripts is how ubiquitous "microtypography" is in them. No two copies of the same letter are ever the same width, swashes and scribal abbreviations are chosen to fit the space available, etc. If you can manage to do that kind of thing on a computer, pretty soon you're doing continuous optimization instead of discrete optimization, so maybe the optimization process becomes a lot cheaper computationally.

I hope you get around to writing up your thoughts! I'd be interested in providing feedback on drafts if that would be useful.