You're right, Kevin, thanks! It's been corrected:

https://github.com/skeeto/skeeto.github.com/commit/a1ebf0e

Yup, I still use that. My system-configuration-options in Emacs 28.1:

--without-all --with-xml2 --with-xft --with-libotf --with-x-toolkit=lucid 
--with-cairo --without-modules --without-threads --without-pop

(Unfortunately "all" does not cover modules, threads, or mail. I wish 
there was a --without-ctags so I wouldn't have to delete it manually.)

Is it still lower latency than the alternatives? I'm not sure. I haven't 
tried anything different for several major releases. Also, the past 
several years I've only used Emacs for Elfeed and Calc, so my interaction 
is limited. If you take any measurements I'd be curious to know. Low 
latency is important to me, too, and boy does all the slow web stuff these 
days drive me nuts.

In regexp syntax, "[:…:]" by itself is a plain old bracket expression. If 
you want to reference a named character class, you must put that inside a 
bracket expression: "Highway[[:blank:]]1" That works when I try it.

Tokenizing the search query and treating tokens as regexps is admittedly 
awkward. I wish I had come up with something that worked more intuitively.

> The apostrophe in the post title is misinterpreted

Thanks for the heads up! I wasn't aware. I'll need to sort that out.

> it can't reorder insertions at runtime

Good point. Encodings aren't difficult, but I lack the requisite i18n 
knowledge and experience to work out a good solution myself for these 
higher level issues. (Though I did pick up Esperanto a few years ago to 
help get insights on exactly this.) My typical localization interactions 
are when it's in the way, behaving badly. Like being unable to parse 
floats (strtod) because the application may not be using the C locale, or 
significant performance penalties when dealing with text.

Sorry, that article was swept away years ago during house cleaning:
https://github.com/skeeto/skeeto.github.com/commit/44ccb23

You can still see a snapshot here, including the old blog style:
https://web.archive.org/web/20130520053347/https://nullprogram.com/blog/2009/04/22/

Thanks for pointing this out! I've deleted the old link:
https://github.com/skeeto/skeeto.github.com/commit/6483e46

The point of the post is to teach you how to do it yourself! That being 
said, my article is more than 15 years old and things have changed, all 
for the better. You should use ffmpeg instead of mplayer, and ImageMagick 
has improved such that the "montage" command is now reasonably fast. In 
fact, you can do it with a one liner without intermediate files:

    ffmpeg -i movie.mp4 -vf framestep=24,scale=32:18 -f image2pipe
        -vcodec ppm pipe:1 | montage -geometry +0+0 -background black
        -tile 60x ppm:- movie.jpg

As noted in the original, you need to adjust framestep appropriately. This 
one-liner uses a technique described in my "Rolling Shutter Simulation in 
C" article.

Interesting! Thanks, Alexander! While I'm not surprised this sort of thing 
didn't take off, it's interesting to see that it was actually used in a 
real system long ago.

> is redundant for the goals of this demo

That atomic store prevents a race condition and is essential. The futex 
syscall atomically loads the futex and compares it to the expected value, 
in this case zero. If the waiter arrives late, it misses the futex wakeup, 
but it won't wait because the value has been changed away from zero. What 
if it's non-zero in the first place? Then if it arrives early it won't 
wait at all, which is bad for a different reason.

So it must be an atomic update followed by a wake-up in order to cover 
both possibilities. If the futex was used frequently, perhaps an important 
and mutex on a hot path, I'd want to avoid the syscall costs when there is 
no contention. I would signal the presence of a waiter through the futex, 
then conditionally wake based on the value. Similarly, on the other side

Clever idea and good thinking! I like it. Next time I need it I might take 
this route.

Interesting, thanks! I had tried something like this myself, but couldn't 
get it working reliably. However, your example works in every case I've 
tried on x86-64. Maybe I was using the wrong built-in before. I was also 
able to grab the environment pointer:

    char **envp = (char **)(argc_ptr + 1 + argc + 1);

Perhaps this will be useful! It also works on ARM64 at -O1 and higher, but 
not at -O0 or -Og. Unfortunate since ultimately it would be nice to have a 
pure C entry point rather than special _start assembly for most targets. 
Here's my test program:

https://gist.github.com/skeeto/e7ff8823d8801a5b483c109fc84b6ab5