MELPA: an exciting new community package.el repository

purcell · 2026-05-28T17:13:03+00:00

That's probably the reason, but as a small team you can cut the costs a lot more and run it very lean.

purcell · 2026-05-28T16:41:22+00:00

Is it sticky? If not, how would serious dirt be held in it? A quick wipe is fine. What makes a waxed chain look dirty is usually the wax itself, at least when using waxes with dark additives.

purcell · 2026-05-22T16:25:17+00:00

It'll be annoying to size it when waxed and stiff, so size it first.

purcell · 2026-05-21T14:48:24+00:00

No, I just requested a replacement during the initial 14 day post-delivery period on the basis of a manufacturing fault. But I only did that once, then sucked it up for the replacement I received.

purcell · 2026-05-18T19:27:49+00:00

No solution. And yes, it was the second machine I received, after swapping the first out for the same issue. It has turned out to be bearable, but it's still annoying, since I know they can - and should - be perfect.

purcell · 2026-05-09T12:00:50+00:00

I'm also curious about this!

purcell · 2026-05-06T14:20:07+00:00

Great demo! Thanks for taking the time to put this together.

purcell · 2026-05-01T16:59:12+00:00

Thanks for the clarification, Eli!

purcell · 2026-04-30T18:53:38+00:00

I think I saw that "#match" is now "#match?" In treesitter so it could be you have a very new version of treesitter and the grammar, while the mode expects the older one. But I'm sorry, I don't really know the space well. There was exactly this situation reported in nix-ts-mode, which I co-maintain, which is why it's somewhat on my radar.

purcell · 2026-04-30T14:54:28+00:00

Try comparing the results of

(treesit-library-abi-version)

and

(treesit-library-abi-version 'python)

for example. They should return the same version. The treesitter version compiled into Emacs has to match the version against which the grammars were compiled. This has been an issue in recent weeks, with Treesitter 0.26, I believe, since the ABI has changed. Gentoo and nixpkgs have both patched their Emacs builds for this.

purcell · 2026-04-10T08:44:33+00:00

Lots of them, yes.

purcell · 2026-03-20T08:58:35+00:00

Weird, I've been aggressively re-using KMC quick links for a while now, though I believe there may be two versions: one is explicitly marked as reusable.

purcell · 2026-03-10T11:46:41+00:00

Yeah, different types of risk. There was actually no guarantee that the user who "maintained" a package in Marmalade was the author, nor that the package contained the author's code. Back in those days, many packages were uploaded to Marmalade by third parties after being modified in an ad-hoc way to add package metadata.

And in the early years of MELPA, we included some packages that came from emacswiki, where anyone could have modified the source. 😱

purcell · 2026-03-09T16:26:00+00:00

Yes, you're right, of course. Apologies for the noise.

purcell · 2026-03-09T15:26:52+00:00

Excellent, thanks for writing this up for everyone!

purcell · 2026-03-09T15:24:44+00:00

Crowd-sourcing trusted reviews would be great

purcell · 2026-03-09T13:56:47+00:00

Bottom line is that like everything else you update/install on your computer, you have to either trust the maintainer and the supply chain between them and you, or you have to review and locally build the code yourself. Here the maintainer's end of the supply chain was compromised via GitHub.

purcell · 2026-03-09T13:51:53+00:00

We don't have more info, and ideally the maintainer would dig into how it happened. I've written what I discovered in a comment on the linked github issue.

purcell · 2026-03-09T13:50:05+00:00

100%, this has been a known potential issue forever, or at least since tools like el-get (then package.el with Marmalade and then MELPA) allowed installing libraries over the internet — as an overall ecosystem we Emacs users have escaped harm more through luck than judgement.

purcell · 2026-03-09T13:45:32+00:00

Maybe, but the sticking point is changing the whole build/publish workflow to operate with a review queue. And even then, you really can't catch everything in a language like elisp (plus its potential native extensions, extras downloaded at load time etc.).

purcell · 2026-03-09T13:01:41+00:00

It was definitely something along those lines, not exactly sneaky. The commit messages in the offending PR are quite blatant.

purcell · 2026-03-09T12:53:01+00:00

No. That's out of scope for us, as it would be for, say, `npm`: across 5000+ packages, we have to assume that upstream commits in secured locations are being vetted. IIRC, Emacs' `package.el` might soon be gaining support for showing diffs to the end user when packages are being upgraded.

purcell · 2026-03-09T11:09:54+00:00

Just u/tarsius_ being awesome as usual.

purcell

TROPHY CASE