back in my time as an (inadvisably) precociously online kid, the only real age barrier was having a credit card, so i had to beg/borrow/steal my way to someone on irc giving me a shell to a vps, and pay some other rando with a steam gift card to buy a domain then transfer it to my registrar account. and like that, i could start developing a presence in whatever online communities i insinuated myself into by acting mature enough nobody gave my age a second thought. physical realities like divorce and school troubles came and went, but moving and shaking online gave me my most steadfast friends and s/o to this day.

shift the timeframe a couple decades and i would have instead been gated by an id upload. bleak.

i recently made use of plenty of ugly tricks in this vein to take a single authoritative table of macro invocations that defined a bunch of pixel formats, and make them graduate from defining bitfield structs to classes with accessors that performed good old fashioned shifts and masks, all without ever specifying the individual bit offsets of channels, just their individual widths, and macro magic did the rest. no templates, no actual c++, could just as feasibly produce pure c bindings down the line by just changing a few names.

getting really into this stuff makes you stop thinking of c function-like macros as functions of their arguments as such, but rather unary functions of argument lists, where arity roughly becomes the one notion vaguely akin to typing in the whole enterprise, or at least the one place where the compiler exhibits behaviour resembling that of a type checker. this was especially true considering the entries in the table i wound up with were variadic, terminating in variably many (name, width) parenthesised tuples. and i just... had the means to "uncons" them so to speak. fun stuff.

this is worth it, imo, in precisely one context, which is: you want a single source of truth that defines fiddly but formulaic implementations spread across multiple files that must remain coordinated, and this is something you do infrequently enough that you don't consider it worthwhile introducing "real" "big boy" code gen into your build process. mind, you usually do end up having to commit to a little utility header that defines convenient macros (_Ex and such in the article), but hey. c'est la vie. basically x macros (https://en.wikipedia.org/wiki/X_macro) on heart attack quantities of steroids.

which is basically ideal, no? for all the buy-in that the systemd stapling-svchost.exe-onto-cgroups approach asks of us, at the very least we have sufficiently expressive system to do that sort of thing. where something on the machine has a notion of what wants what from what, and you can issue a command to see whether that dependency is satisfied. like. we are there. good. nice. hopefully ops guys are content to let sleeping dogs lie, right?

...right?

if argon tickles your fancy, you might also be interested in fragment mono (https://github.com/weiweihuanghuang/fragment-mono) a similar free software “helvetica mono”.

the tragedy of both argon and fragment mono, though, is that the latter comes in one width, and the former inexplicably supports obscenely wide proportions without letting you condense it down from the bog-standard 1x2ish. most condensed options out there are these pill-shaped straight-walled monstrosities that blur together (the iosevkas and pragmatas of the world), with a few notable exceptions (the old osdn releases of mplus).

i wonder what would happen if you went in and extrapolated the width scaling for monaspace backwards into super narrow range.

having used all the 3.0 RCs up till now, i can assure you all gtk3 has done is made life nicer on all major platforms. for gimp's faults (now markedly fewer) it's an image editor, a thing with a distinct purpose and pretty immediate feedback on indulgent changes nuking productivity. the cancerous low-information-density, look-over-feel trends that we associate with new gtk versions by way of gnome's visionless bikeshedding blessedly does not translate to this new gimp. pinky promise. go use it. you'll like it.

it's my go-to for lining up pixel-perfect uv maps for more geometric/mechanical 3d assets -- the recursive nature means you can have an easy time hitting, say, the exact corners or centers of luxels if you feel the need.

just the other week i noticed a change in recommended formatting style in a project i contribute to regularly, and the result was source files got about 20% taller, 20% more of a pain in the ass to edit without some sort of syntax folding. the rationale? diff. making you reach for a syntax-aware editor to compensate for a deficiency in the syntax-awareness of a version control frontend is certainly a choice.

the business end of git as seen by most programmers is in fact diff city, sure, but deep down git is a bunch of snapshots. even deltas behave nothing like diffs. pull up the spec for the pack format and look for the word "line". you will not find it.

things could be so much better, but for now we live in a world where the headline is true.