A few years ago, I amended the Emacs package for WordPress so that it automatically grabbed a screenshot of whatever I linked to. That’s a low effort solution to the link rot problem — i.e., inevitably, all web sites die, and your blog ends up talking about web sites readers can no longer read.
Now, the Wayback Archive helps a lot with this, but it doesn’t have everything. Doing a “real” backup of web pages, HTML and all, would of course be better than screenshots, but that requires a lot of effort (considering all the security implications of running foreign JS on your own site, etc). So doing screenshots is, of course, not a perfect solution, but it’s a lot better than nothing. At least your readers can read themselves the things you’re talking about.
Anyway, I’m doing this post because the original way the package displayed the screenshots was just bug ugly. So I’ve now changed it:
I think that’s kinda useful, eh? (You can try it yourself with the links above, for instance.)
Anyway, the resulting Javascript and CSS is on Microsoft Github in the ewp package. I’m not actually expecting people to use this code as is in their WordPresses — I just hope somebody writes a WordPress plugin that does all this automatically (on the server side, without any client support). Because I think everybody who blogs should be doing this — there’s nothing as frustrating as searching for a subject, and then landing on a ten year old blog that talks about that vaguely, but all the links are now dead.
I’ve had code for ages to handle images automatically in Emacs and the WordPress Emacs package, but it hasn’t been integrated well before, and it’s been a bit hacky, leaving temporary files behind and stuff.
So I’ve now finally cleaned it up, and here’s how it works in practice:
See? Blogging with images is easy in Emacs.
Now, for this to work, you need a camera that uploads snaps automatically, of course. I use a Sony a9, but there’s many options out there — or you can use a wifi SD card, like I talk about in that blog post, too.
Which reminds me: I was wondering whether the new Sony a1 II camera is good for my use case. The a9 is almost perfect, but since I’m shooting one-handed in low light conditions, it sounds like the a1 would be even perfecter. (That’s a word.)
Of course there are no real reviews for the thing I’m interested in: Does the wifi FTP functionality work as well on the new a1 as it does on my a9? But I found this:
Eeek! “Improved FTP capabilities and integration with Sony’s Creators’ Cloud for automatic file uploads to services like Adobe Lightroom or Google Drive” could either mean that the FTP works as before (i.e., it works really well locally, too), or it means that they only allow “improved” FTP towards “Sony’s Creators’ Cloud” or the other central storage solutions, which isn’t what I want at all. That’d be horrible. I hate improvements sooo much…
Anybody happen to know? Many other cameras also offer automatic upload functionality, but most of them also use some crappy cloud solution instead of local FTP — I’m running an FTP server on this laptop, and the camera uploads the images directly to the laptop. It’s fast and reliable.
I mean, the a9 works well, so I’m in no hurry to switch, but…
Everything is cyclical in computing, so people move between writing things in raw HTML and using arcane and unholy systems, mostly based on some Markdown dialect. I understand the frustrations: It feels like there should be something that’s less annoying than using some WYSIWYG tool that invariably freaks out and ruins your post, or typing all that annoying HTML yourself, or using Markdown and then having to have some kind of build step.
In my opinion, Markdown is fine for writing README files, but if you’re writing blog posts, it just gets in the way. A blog post is mainly just paragraphs like the one I’m typing (and you’re reading) now, which is just text with no markup. Or there’s some slight formatting for emphasis or the like, but honestly, there’s not much difference between the HTML and Markdown versions for that.
Markdown is nice for headings and code snippets, but doesn’t really offer much useful for blog posts. And the things that blog posts need, which is images/screenshots and links: Markdown doesn’t help you much there.
Is that really better than the HTML version? And what, then if you need more stuff in the link?
It just gets worse and worse — what if you need to put more data into the links? The nice thing about HTML is that it’s well-formed and not very hacky — the more cruft you add to the HTML, the more unreadable it gets — but linearly. Markdown makes the easy stuff trivial, and the difficult stuff worse. (Here’s there the Greek chorus of “but you can just write HTML in Markdown” comes in, but that’s worse than just writing HTML in the first place.)
So: I write HTML, and Emacs takes care of displaying the images I’m linking to, so a blog post looks like this while I’m writing:
(To digress: I’ve noted over the years the many, many posts on HackerNews about statically generated blogs, and people have more fun spending time tinkering with their setups than actually writing blog posts, and that’s fine. But I’ve noted that virtually none of these systems have a mechanism for dealing with images in a natural way — because that’s just kinda hard. The nearest you get is “then you just create an S3 bucket and put the image there, and then you go to the AWS console to get the URL, and then you paste that into the Markdown here. See? PROBLEM SOLVED!!!” That’s why blog posts from all these people (random example) are almost always just walls of text.)
Anyway, here’s my problem:
YIKES! WHAT THE… Yes, I hear you.
To protect myself a bit against link rot, ewp screenshots everything I link to automatically. So on the blog, you can just hover over a link to see (and read, if you want to) what I was linking to at the time, and that will survive as long as my blog survives (while most of the things I’m linking to disappear, apparently).
But that means that I have to stash that data somewhere, and I stashed it in the links, which means that the HTML then becomes unreadable.
This is Emacs, however. What about just hiding all that junk?
Yes, that’s the same paragraph with the links hidden. And if I want to edit the links themselves, I can just hit TAB on the bracket:
And TAB again to hide:
Note that the links and stuff are still present in the Emacs buffer, so the normal Emacs autosave functions work perfectly, and there’s no danger of losing any data.
Similarly, the image HTML in WordPress can be pretty messy:
Because images have extra classes with their IDs, and you can click on images to get the full sizes, so they’re (almost always) wrapped in an <a>. Now, when writing articles, Emacs displays the images instead of the HTML, so we don’t see all that cruft anyway, but when editing image heavy articles, it can take some time to fetch the images, and we don’t want to be staring at junk like that while waiting for the images to arrive.
So let’s hide them like this:
And TAB can be used to cycle through the three different forms:
I think that looks kinda pleasant to work with…
Anyway, I think that’s as far as I want to go with hiding the HTML-ness of things. I mean, the temptation here is to start going in a more WYSIWYG direction, and translating <b>…</b> into bold text and all that sort of stuff, but… I’m more comfortable just looking at the tags?
So there you go: In the “just write HTML/no don’t write HTML” wars, I’m on “just write HTML but have the editor hide some of the worst of the cruft” tip.
Oh my gerd! This is awful! On a sentence by sentence basis, this is gruelling. “The kettle screamed its achievement of boiling water and Adrian jerked it off the element, wincing.” This is torture.
I got to page 30 before giving up, because the concept here sounds like it could be fun. So I checked Goodreads:
There are bad books. There are books that just aren’t for me. But this is the biggest train wreck of a book in recent memory.
Almost immediately, what we might have imagined as the main story thread on board is mostly thrust aside in favour of long, dull flashbacks filling us in on the characters on the shuttle back on Earth and their relationships to Mal. None of these characters are very interesting and it all feels like a massive distraction. Except that, as it turns out, the murder itself gets pretty much forgotten.
So… I’m ditching this. I mean, I like reading trash, but the trash has to be somewhat well written, at least.
I’ve got a strange kind of cold this week — it doesn’t seem to get better or get worse, but just remains at a stage of me feeling slightly cruddy, so I’m picking books to read that go down easily. I’m not up for reading anything challenging.
I bought this book in 2005 and then didn’t read it. I’ve read the previous books in the series, but I guess I just decided that I’d read enough of these books? And then bought one more anyway, but never read it. But now I’ve brewed a cup of bush tea, so let’s go.
(I think I started drinking that stuff after I read the first book in this series?)
I think that people should write stories featuring whatever people they want to dream up. But it’s sometimes hard to completely disregard the paternalistic tone the white author here takes with his African characters. It’s often like… “eeeh?” (Such erudite critique.)
But this book sure goes down easy. We’re presented a number of low stakes mysteries, and most of them are solved. I tend to think that the author has a tendency to forget all the plot strands?
I did indeed enjoy reading this book while hacking slightly, but I don’t feel compelled to buy any further entries in this series. I see that there’s now 24 or these books? Geezes. Perhaps reading one of these books every 20 years is enough?
