...actually, that's a lot longer than I expected, so I think I'll tweak it a bit and post it to my blog.
I just need to vent for a moment.
The #1 thing a blog post editor should do is make sure you NEVER LOSE WORK... and the sooner I can find time to satisfy my obsessive dedication to never 404ing URLs while switching to a static generator, the better.
WordPress deserves an *award* for how readily it destroys your work.
Try to edit a table or a definition list in the raw HTML for lack of visual access to a desired feature and oops your manual tag-balancing? It garbles everything up on switching to the WYSIWYG view to preview your work without pushing it public.
Misunderstand what the buttons on the "Invalid HTML. What do you want to do?" popup mean? There's no Undo so you better hit Reload instead of Save.
Want to edit stuff naturally in the new Blocks editor? Good luck. The interaction between cursor motion and selection means that trying to select a paragraph of scratch text without reaching for the mouse will snap the selection to the entire block, including text outside your intended span.
I just *lost* a big edit to an old list post because, for reasons I can't even fathom, switching from TinyMCE to raw HTML reverted it to the saved version.
Wanna save? Better make sure you didn't leave the tab open too long or it'll get stuck on that "Saving" message that replaces the "Save Draft" button.
Wanna use the preview function but have your browser set to only allow new windows/tabs to be opened by an explicit middle-click or context-menu choice? Too bad. The Preview button can't be middle-clicked.
When I remember, I've taken to editing my blog posts by switching to HTML mode, copying them into Vim, and only copying them back once I think they're ready.
*chuckle* Just checking through a Rust crate for preliminary file accessibility checks that I want to do as a CLI argument validation step.
The UNIX/POSIX version is just an API wrapper around faccessat().
WinAPI makes doing the same thing so verbose and complicated that the author felt a code comment was necessary that says "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn".
I just remembered a fascinating post on the history of the number sign which I thought everyone would appreciate:
Also, two other good posts from the same blog:
Just a little bit of fan #music I ran across:
SylphStorm's redux cover of "Neverending Strife" by H8_Seed.
If you're not a fan of bronies, don't hold it being MLP music against it. Catchy music is catchy music and, like "In The Dark of the Night" from Anastasia, it sounds *great* on its own even if you don't know the context.
As a side-note, did the casual self-introductory "don't worry, I'm just the villain" start remind anyone else of "Brains!" by Voltaire?
After encountering a public domain tileset on itch.io that appealed to me so much that I'm now considering experimenting with game development, I decided to start compiling a list of game assets on Itch.io that are under Debian-compatible licensing terms.
(i.e. Not the usual "don't redistribute or sell alone or in assets packs" terms which violate the FSF, OSI, and Debian definitions of Free and/or Open.)
(The description also lists other sources like OpenGameArt.)
...and huh. So that's how horizontal and vertical tab characters were supposed to work in smart peripherals in a standardized way. The C1 extensions to ASCII for extended control characters say 0x88 is supposed to mean "set a horizontal tab stop at the current cursor position" and 0x8a is supposed to mean "set a vertical tab stop at the line the cursor is currently on."
There's also apparently 0x95, "Message Waiting" which, judging by the description, is supposed to be like BEL but setting an indicator that's persistent until dismissed.
Apparently ECMA-6:1985 and ASCII-1986 declared UNIX line endings deprecated in favour of DOS/Windows-style ones and ECMA-48:1991 declared them disallowed... shows how well that worked.
(Source: https://www.aivosto.com/articles/control-characters.html#LF )
I just thought of a good way to respond to people who grumble about younger generations lacking skills that used to be taught as essential. (eg. beautiful handwriting, being able to catch bugs in your output effectively enough to do it on real dead-tree paper before ever submitting it to a computer, etc.)
"No one disputes that it's a useful skill to have. The question is whether the value you'll get from it in this day and age justifies continuing to ask people to invest time into it as anything other than a hobby."
There are plenty of useful skills that used to be essential to at least some segment of the population and are now hobbies. Horse-riding, carpentry, calligraphy, ballroom dancing, etc.
Sorry I went silent. I've been too busy to even check Mastodon, let alone post on it.
Today, however, I self-nerd-sniped and implemented a one-click aspect ratio correction userscript for 320x200 screenshots of DOS games on MobyGames:
(See https://www.gamasutra.com/blogs/FelipePepe/20150423/241730/No_MSDOS_games_werent_widescreen_Tips_on_correcting_aspect_ratio.php for an explanation of why it's necessary.)
I just got nerd-sniped by an old Tom Scott video which touched on bodging multi-keyboard input.
The funny thing is, Linux is technically easier to do this bodge with, but it's the documentation that holds it back.
Want to bodge it through evdev? Good luck learning to permanently adjust udev permissions.
Want to use XInput2? Qt and GTK don't expose the relevant field, so you have to learn raw X11... which doesn't have the best documentation.
Another two thoughts I'll have to remember to send upstream:
1. With local timelines making it possible to actively follow everything local, it'd be really nice to have something milder than "Mute" so I can remove arXiv Quantitative Biology from my local timeline but still see exceptional entries that get mentioned by people.
2. Posts should have an "I'd like to be notified of people's answers to this too" button.
I've been using COVID as an opportunity to deep-clean the couple of used Unicomp buckling-spring keyboards I snagged at a good price as spares (since they don't make standard US104 layout anymore) and I noticed that one of them not only had the separate keycaps and keystems, but that it had a whole bunch of different colors of keystems, so I decided to have some fun putting them back in.
(Yeah, the keys that are always one-piece designs are yellowed. I'll order some replacements eventually.)
@freemo To clarify, I do understand that it's served up by the site that hosts the post I'm trying to fave/reply to/etc.
I'm asking whether an option could be added to opt out of it when both the user and the post are on qoto.org and, thus, the code serving up /interact can see my session cookie.
@freemo Given how much I use middle-click as part of a "triage first, read and fave later" workflow, do you think we could get an option in qoto.org's Preferences to skip the "/interact" page (the page with the "Proceed to ..." button), rather than just pre-filling the username?
For anyone who might be following this for updates to existing entries on my blog, I've added "YouTube's Copyright System Isn't Broken. The World's Is" and '"Games as a service" is fraud.' as related mentions in my "The Most Eye-Opening Things I’ve Ever Read" post:
I just ran across an interesting and highly detailed blog post from 2014 about the Intel x87 fsin instruction.
No big surprise that it's from Bruce Dawson's blog. I really need to do an archive trawl of it some day.
Linux user, open-source enthusiast, science buff, and retro-hobbyist who occasionally reviews fanfiction.
QOTO: Question Others to Teach Ourselves. A STEM-oriented instance.
No hate, No censorship. Be kind, be respectful
We federate with all servers: we don't block any servers.