Honesty gets Emacs patch rejected

home

2026-06-25

Honesty gets Emacs patch rejected

I’ve been working on Emacs performance on macOS for a couple of months - not continuously but for couple of months nonetheless. During that time I’ve been occupied with hooking up instrumentation and creating benchmarks. I also gave multiple LLMs the codebase and asked for it to search for specific things. Usually the results were poor. After analyzing patches, either the impact was minimal or the problem was misunderstood - something completely expected.

Though over this time I formed some opinions about the codebase I believe are true.

Opinions, that on macOS the main problem with performance consists of rendering issues and memory thrashing - happening with rapid allocations and deallocations. Opinion, that lack of memory compaction, specific to macOS due to how system malloc works, causes virtual memory bloat and loss of cache locality. Opinion, that Emacs core is not free of performance issues. One place I’ve been analyzing over and over was regexp processing. It’s used everywhere and so any improvement to regexp processing would improve the overall performance.

I’ve been re-analyzing over and over these areas. I’ve made some rough patches and was slowly narrowing down the scope with hope of getting to tangible, fixable, points.

Recently, thanks to z.ai Max plan granted to me by my friend, I’ve been able to run GLM 5.2 on projects I’m working on (these ones where I could). I discovered that GLM 5.2 is quite capable when it comes to code optimization and so I decided to ask specific questions about Emacs within the context of already amassed knowledge, and made it to search and analyze any issues.

Without going into much detail, after ~3 hours1 it came back with couple of reports. I reviewed them, the propositions and provisioned code, tested the impact of each and ran benchmarks. Because grooming code for a patch submission takes some time I picked the most promising one and started to work on it. I sent it to emacs-devel mailing list two days before writing this piece.

Day after I learned that it won’t be accepted as there is a GNU policy against accepting LLM-assisted work. I respect it but I don’t agree with it.

To give more context: in the mailing list when I was sending the patch, I noted that:

The issue was found and patch drafted by GLM 5.2 (a Chinese model with open weights).

I analyzed the issue report for correctness and impact

I reviewed the patch and made modifications to it

I tested the patch manually

I declared authorship of the submission for legal purposes (i.e. I’m prepared to argue that my contribution was bigger than LLMs)

I declared taking full, personal, responsibility for the submission

Submission size and implementation scopes are very narrow. I don’t think it can be categorized as slop, but feel free to make your own opinion (the patch is 92 lines long and includes the raison d’être in the comment).

And it bounced.

Personally, I don’t think the policy has any basis.

First of all, I could’ve hidden the fact of LLM usage, and yet decided to declare it explicitly. By being truthful I already lost my footing. This alone makes the policy stupid. If admittance is punished it’s better to push submissions without admitting. It punishes integrity, not usage per se. Because who will find out? I don’t trust LLMs at all thus I believe LLM-assisted work require actually MORE scrutiny and eyes - not less.

I don’t claim to known full context around the policy because - adding insult to the injury - this policy is discussed on the internal GNU lists. What I learned from past conversation around LLMs, however, is that the doubts about LLM contributions are around them being “open enough” and “legal to use”.

When we’re talking about open-weight models, I find the argument about being open absurd. It means that Qwen 3.6 on my local setup is fine, but if I use it from OpenRouter - then it’s not. GLM 5.2 IS Open Weights model and if I had 256 GB of RAM (which I don’t) and 24GB of VRAM (which I have), I could run it on my local machine escaping the whole “SaaS is closed” argument. By the same measure, maybe Internet access should not be available during crafting of submissions? Internet is full of non-free content, and thus patch might have been tainted? Who knows, maybe the inspiration was taken from *gasp* non-free book or article.

Regarding legality argument - I think it’s hubris talking.

With all the sympathy I have for GNU organization, it neither is the biggest, smartest or the most legal-wise caring organization in the world. E.g. gaming companies are way more paranoid about IP and LLMs and yet usage there is visible as well; ChatGPT has a billion of active users; hundreds of thousands, if not millions of organizations...