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 hours¹ 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 - commercial and not, are using LLMs output every day. And for them the case is clear.

I’m not an American Lawyer, but I read that:

The (Copyright) Office will not register works produced by nature, animals, or plants. Likewise, the Office cannot register a work purportedly created by divine or supernatural beings, although the Office may register a work where the application or the deposit copy(ies) state that the work was inspired by a divine spirit.

And as far as my, IANAL, personality understands is: the problem is with putting a copyright stamp on it and not other way around.

Yet GNU believes that THEIR lawyers and THEIR opinion has the most weight. I won’t deprive them from the right of deciding for they own, but this lack of self-awareness is almost caricatural.

GNU has a freedom to decide about itself - I have my freedom to criticize it. In my eyes behind the doors discussion, without as much as transparency toward users is just as open as Meta internal decisions about Facebook direction. I wouldn’t call it open, neither I would call open organization that decides to operate in such way.

With my rant about politics finished, here’s the actual effect.

I’m not going to work on Emacs anymore. I dislike when people tell me I’m holding the stick wrong - especially when I work on something out of my own volition. On my hard drive I have around 40 performance improving patches, some overlapping, some yet unproven about actual impact. I published only handful that I recently confirmed to work and have a meaningful impact.

Feel free to check them out, as they genuinely² make a difference.

And with that I think I’ll move to more “open” waters.