Kevin Turner @keturn@toot.cat

infotainment high-five apophenia markup language support system

The reason I've been working out how to scroll by column is, of course, so I can make landscape-mode layouts for reading web fiction, like https://gitlab.com/keturn/multicolumn-ao3-usercss

`position: sticky`

Neat CSS rule where the element starts off positioned as normal, until you try to scroll it away, at which point it sticks to the edge.

https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Positioning#position_sticky

I was about to write "`scroll-snap-type: mandatory` is not sufficient on its own," and I went to double-check.

I *do* have scroll-snap working so Firefox's default handling of the right arrow key gets to the next column.

But not left. It must always round up or something, so 1 + 0.1 = 1.1 → 2, but trying to go backwards 2 - 0.1 = 1.9 → 2.

I've had some success combining this with Scroll Snap, which is a handy thing for this use case:

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Scroll_Snap

where my arithmetic gives me a close-enough value and then scroll-snap will snap to. But it would be nice to not need to both add the keybinding *and* manipulate the document's CSS.

Know what's great for long-form text on these widescreen monitors? Multi-column layout!

And CSS has columns these days.

So just as long as there's an easy way to advance to the next column or page…

https://column-scroll.glitch.me/

haven't quite got it. A column isn't exactly an element in the DOM, so I'm having trouble accurately querying its width, in order to know how much to scroll.

I was tipped off to this when looking at the source of Colorful, which I noticed was mathing up the color codes from RGB values in these low-color modes, instead of having some 8-value lookup table.

https://pypi.org/project/colorful/

In the days of 8-color displays (or 16, where the the second half was just brighter versions of the 8), I never saw a pattern in the order the colors came in for things like ANSI X3.64 codes. I assumed they had their small set of colors but the order was arbitrary.

But 8 is how high you can count in three bits: one bit each R, G, and B. The direction may differ between implementations; looks like ANSI X3.64 has Red as the lowest and CGA has Blue as the lowest. But the order of the colors just comes from counting up in binary.

0 0 0 - black
0 0 b - blue
0 g 0 - green
0 g b - cyan
r 0 0 - red
r 0 b - magenta
r g 0 - ~yellow~ brown?

They made a special case for brown, where the green bit only counts for half, because they thought it made a better palette than a dull yellow: https://en.wikipedia.org/wiki/Color_Graphics_Adapter#With_an_RGBI_monitor

Never would have guessed they went to extra expense for that CGA brown!

Using jq to parse output from snapd to generate commands to run through sudo is a fine activity for a winter evening, right?

https://gitlab.com/snippets/1927120

I bet I was doing something else entirely before I stumbled across those old installations…

Clocks? Is the answer "clocks"?

Because the lower numbers are more common, not so surprising to allocate characters for some low numbers but not _all_ numbers, but then why twelve, and not ten or thirteen or fifteen or twenty?

Clocks go to twelve and are often marked with roman numerals.

Why are there distinct code points for the roman numerals one through twelve? https://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7Bsubhead%3DRoman+numerals%7D

I guess they've been there since Unicode 1.0, so Wikipedia doesn't have any links to the proposals for their inclusion.

Slept for something like thirteen hours last night?

Minus a couple interruptions (including when I woke up, surprised to find I'd slept through midnight, and moved from couch to bed), but a lot of sleep regardless.

That's one way to bring in the new year. 💤 🎊 💤

I made some skits showing the program I've been learning Rust with. https://keturn.gitlab.io/execthis/casts.html

(thanks asciinema, you're pretty great.)

THE LIFETIME AS DEFINED ON THE METHOD BODY DOES NOT NECESSARILY OUTLIVE THE LIFETIME AS DEFINED ON THE IMPL

And my rust-produced executable is a lot bigger than I expected. That's also the sort of thing I only noticed because of this low-footprint goal; it's a concern that will vanish as you move into medium-size programs.

I'm enjoying this as a learning exercise, but practically speaking, is it a good fit for this case?

Maybe should have stuck with Python, assuming there's a shared instance of it already installed on the target. Which would be true of pretty much all Ubuntu-derived installations (it's in ubuntu-core), but maybe it's not as core to Debian as I thought, and it's unclear what runtimes will be available to future versions of OS X. 🤷

Making guesses about portability is hard!

(The initial impetus for this utility was something I couldn't figure out how to make readable in POSIX sh/sed/awk.)

So far, I think this Rust language is probably fine for writing and maintaining programs in.

I'm writing a tiny little utility. It needs so little from a runtime, and it's so peripheral to the system's core concerns, I thought stay-small-and-load-quick would be good qualities.

Seemed like a good candidate for an experiment with Rust, given its ahead-of-time compilation and lack of overhead for memory management.

What I've got so far — which barely does more than parse its arguments — is faster than a minimal CPython program and takes less memory, but CPython doesn't do so badly in comparison.

(I expect they probably scale very differently once you move out of this teensy-scale program; Python imports can accumulate fast.)

the documentation browser is real nice though. That search interface!

Oops, stayed up all night learning Rust.

socat -t0 -u EXEC:"$*",pty EXEC:"less -rF -",pty,ctty,rawer