Skim v1.0.18 — "Mind the closing boundary" 🧱
The one where we stop blaming you for emails that render as a beautiful, pristine, completely empty rectangle. Turns out it was us. Well — it was the sender's mailer. But we fixed it anyway. 🕵️
🐛 Fixed
Blank emails are no longer blank. Some mailers finish a message on the last base64 chunk and just… walk away, never writing the closing --boundary--. The MIME parser reads that as "this part is broken", quietly demotes your email to an attachment, and hands us nothing to show. Skim now closes those dangling multiparts itself (innermost first, like a polite houseguest turning off the lights) and parses again. Your booking confirmations are back. 📬
No more phantom attachment. That mystery .bin full of raw base64 sitting under the empty email? It was your email. It has been returned to its rightful place. 🎭
Bad parses no longer latch forever. The old code cached "I fetched this" and "there's genuinely nothing here" as the same thing, so a message that failed to parse once stayed broken until the heat death of the universe. Now Skim can tell the difference and gives previously-mangled messages one more honest attempt. ♻️
Truly empty emails say so. If a message really has nothing to render, you get a plain line saying that instead of headers floating above a void. Silence is not a UI. 🫥
Stale attachment files get cleaned up on refetch, instead of quietly squatting on your disk forever. 🧹
🌍 Everywhere
The new "nothing to show" line is translated across all 11 locales, because a blank pane is confusing in every language. 🗺️
🧹 Housekeeping
Three new tests that fabricate exactly the kind of broken email that started this whole mess, so it can't come back. 🧪
Get it here: https://github.com/nikserg/skim/releases/tag/v1.0.18
Replies
the ''silence is not a UI'' line gave me a laungh. small details like that can make the product feel much more polished.
This is the same bug we were talking about this morning, one layer down. A missing closing boundary means "I do not know where this part ends", and the parser rendered that as "there is nothing here". Unknown collapsing into empty again, just in MIME instead of in the UI. Which suggests the fix generalises beyond the parser: anywhere you turn a parse failure into a value, ask whether the value you picked is distinguishable from a legitimate result. Empty is a legitimate result. Broken is not, and it should never be able to impersonate one. Nice catch on it being the sender's mailer and shipping the fix anyway. That is the right call and most people would have closed it as not our bug.
i appreciate that you added tests for the exact issue. that's usually the best way to make sure the same bug doesn't come back.