TLDR: dude writes a textbook example of a basic event loop in C (which reads inputs, then renders), calls it the “unidirectional UI pattern,” which “is an attempt to bring data-driven programming to the UI world.”
Why so negative? Someone coming from a different world to learn something new should be celebrated, even if he uses his homeworld’s language to describe the experience.
Which part of the summary is negative? How?
Quite often TLDRs with quotes are written to be “sarcastic”. My bad if this was a sincere TLDR, but it could easily be read as something else.
It was intended to be sincere. Maybe I’m an impatient person but I feel like I have less and less time to carefully read articles these days, and it’d be really nice to have a short summary that spoils the grand insight before I even begin to read. That would make it easier to focus my time on the ones I can learn most from.
This particular article spends a little too much breath on background and introduction, and the almost-clickbaity title doesn’t do much to help the reader know what it’s all about. Since I read it, I figured I’d share my summary to help other people in my situation.
I don’t think VI is implemented like this. I think it is done more like the first style with ad hoc rendering of different elements directly in response to events. In the second style there is a global model of the UI state which has mutations applied before rendering.
I don’t really care how some old editor does it. However, the event loop has been a standard way of doing things in games and desktop applications since time immemorial. I’ve written a vi-like editor myself which does the same. With the caveat that it has multiple event loops, to implement interactive commands (this is just encoding the state of the application in control flow instead of rolling it all up into one massive top-level loop with a ton of explicit state).
If we look at OpenBSD’s copy of nvi, it uses a very similar model, with the main event loop in vi() in vi.c and another one (v_txt) for insert mode & co in v_txt.c. The screen is updated between each run of the loop (grep for vs_refresh, vs_repaint). The commands that actually edit the buffer (e.g. x and X) are unaware of the display side of things, and much of the actual buffer-modifying code lives in a different subdirectory altogether and is shared between ex and vi. It’s a bit hairy but the structure is there, more or less.
Why it’s done this way becomes immediately obvious when you implement things like macros or mass-substitute. Such commands could be incredibly slow (especially so on hardware from the vi era, but it’s relevant even today) if they posted screen updates (that won’t be visible anyway) en-masse.
That said I read some of the C code in the repo and it seems pretty nice. It would be nice if the two were more closely connected.
Then I’ve got something you might find interesting: the old manuals for the LCC-Win32 IDE, which contain a really nice overview of all the systems the author wrote or modified (from the C optimizing compiler to the resource editor and Wedit, the text editor.)
I remember reading these docs about… 15 years ago? (holy crap!) and they were a great introduction to a lot of topics. The newer versions of the compiler don’t include these docs anymore, which I consider a shame.