Anjou

I have to say that both quantity and nature of LLM enthusiasm in my chosen field is truly eye-opening.

@lookitup.baby I need you to look at this and feel the same thing I do.

Notification from LinkedIn: People are viewing Jean-François Lesseliers' post: Jamf is present at the Global Police Summit in Dubai. Hashtag Dubaipolice is the main sponsor. We're showing our Jamf Executive Threat Protection hashtag JETP hashtag jamf to Law Enforcement departments around the world to help them detecting sophisticated mobile attacks on their VIPS Come & meet us at Hall 6E3B

The fucking face I made when this notification popped up about a former employer.

I was on a call with some folks from Dell, talking through their product offerings, and on the topic of monitors even larger than this, one asked "who wouldn't want even more monitor?"

I did have to chime in to say "me, I don't want larger monitors."

I want a pathlib.Path for URLs, so I'm writing one. I wonder whether it's the sort of thing I can push to have added to the standard library.

Alright, I guess I'll add a post-processor that just looks for the wrong quotes and fixes them. It's not elegant, but whatever.

Well, except for one small detail about how the parser works, where it replaces parts of text with a bunch of magic strings as it goes, making some regexes simply not match if they require context which is no longer available.

It took ages to figure out why a regex wasn't matching like it should.

The smart quotes implementation looks like just a pile of regexes registered to perform their transforms during the parsing. Seems easy enough, I'm good at regex.

Now we're back to smart quotes issues again. This implementation is wrong far more often than kramdown's, putting open quotes where there should be close quotes and vice-versa. Time to fork that code too, I guess!

So if you want two blockquotes, one following another, with different attributes? Well, I found on a comment on a Github issue that includes the source code for an extension to break those up. Alright, I'll use that too, I guess.

Except that now I'm running into the fact that python-markdown is "proudly" an implementation of John Gruber's original markdown, warts and all, and it has other limitations. Like, for example, there is no syntax for separating two blockquotes adjacent to one another.

Okay, alright, I can make that work. I just need to add a preprocessing step on the raw, unparsed Markdown to distinguish the cases. There, working!

Fine...except that kramdown has two different versions of the syntax to allow applying the attributes to either the blockquote as a whole or to any given paragraph of it... and python-markdown's parser doesn't expose the distinction in the syntax tree visible to the extension.

Okay, well, this time I found an extension that tweaks the behavior of block attribute lists so that they can apply to almost all of those things...except blockquotes.

No problem, I can just fork it and extend the logic to support blockquotes.

I'm really trying to avoid rewriting all my Markdown to accommodate an even-more-special parser. So I switched to python-markdown.

Good news: their attribute list syntax is practically identical! Bad news: unlike other implementations, it can't apply to blockquotes, ul, ol, and some other tags.

Well, that's...fixable. Annoying, but fixable. The bigger problem is that the official attribute definition plugin uses unresolvably different syntax from any of the other markdown implementations of it I've run into. Block attributes in this plugin go *before* the block, not after.

For the unaware: in English it is standard typography to have unmatched open quotation marks for quotes that include paragraph breaks. An implementation of smart quotes for English text should not treat this as a syntax error and fail.

I first tried markdown-it because it advertises itself as a Commonmark implementation. The first issue I noticed was that the smart quotes feature is broken. In another example of programmer-brain, it doesn't even try to handle unmatched double quotes.

I found two currently maintained Python libraries for handling Markdown which purportedly included support for the extensions I'm interested in. They are markdown-python and markdown-it-py (a straight reimplementation of the JS markdown-it library).

Neither matched kramdown's output.

I should have known better. John Gruber's original markdown spec from 20 years ago had a lot of ambiguous edge-cases. I thought the world had largely converged on a common spec (Commonmark), and even a widely shared library of common extensions (e.g., smartypants, attribute lists, tables).

The Jinja2 part of this project was the part I thought would be hard. No. I'm sorry. This was the easy part.

The hard part was, shockingly, the Markdown parsing... the part I *thought* would be easy! It's just markdown, right? There are a million parsers out there for it, right?

That's the character class for "word," right? Good enough, right? I mean, I guess, as long as you're okay with saying "Bob's Burgers" is three words. This algorithm way overshoots the word count of typical English writing.

Hilariously, I had to write my own word count filter because Jinja2 doesn't use the stupid-simple "count the number of things separated by whitespace" algorithm. Instead it uses the very programmer-brained "count the occurrences of the regex `\w+`".

A bigger issue is with the include syntax. Jekyll uses a scheme where it passes arguments through to the included template, and Jinja just has the included template inherit context. Still, not a big deal to work around.

Add some extra functions for the filters that have no direct equivalent in Jinja, intercept the token stream to swap out the filters that do, and also use the token stream to rewrite Liquid-style argument syntax for Jinja-style.

I decided to write an extension for Jinja2 to work as a translation layer between Jekyll/Liquid template syntax and Jinja's. They're very similar! And despite the rather lackluster docs about extension development, 90% of this part was pretty easy.

It's the programmer's hubris: We do things not because they are easy, but because we thought they were going to be easy.

I got it about 98% done over the weekend, and the punchline is that it was not, in fact, easy.

So I started building my own Jekyll out of parts, with Jinja2 instead of Liquid, markdown-it instead of kramdown, and pyyaml for parsing front-matter.

Seems straightforward enough, right? I can write just enough glue to make it work almost the same way, then tackle the edge cases one by one.

Well, alright. Let's switch static site generators. It'd be nice to use one based on Python, since I've already got a bunch of Python helper scripts for building my site.

Now the problem is… I'd have to rewrite all my templates, configs, and everything, and I have relatively complex logic in those.

[Bug]: Impossible to use Jekyll on FreeBSD · Issue #9462 · jekyll/jekyll Operating System FreeBSD 13.2 Ruby Version ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-freebsd13.1] Jekyll Version jekyll 4.3.2 GitHub Pages Version No response Expected Behavior I expected...

Well, there's one small problem... Oops, I was looking at a hosting provider that runs FreeBSD. Now, there are workarounds, sure, but I'm not thrilled about pinning an older version of a dependency indefinitely, and I don't want my build step to be more complex than "git push."