June 25, 2026
Ctrl+Alt+Drama
Honesty gets Emacs patch rejected
He told the truth about using AI, and the internet instantly split into Team Honesty vs Team Slop
TLDR: A programmer says his Emacs fix was rejected after he disclosed that an AI helped draft it, turning a small software patch into a big trust debate. Commenters split between mocking “vibecode slop” and arguing the rule punishes honesty more than bad work.
A programmer says he found a promising speed fix for Emacs, the famously old-school text editor, after using an artificial intelligence tool to help analyze the code. He says he checked the results himself, rewrote parts, tested the patch, and then did the one thing the internet usually begs for: he was honest. That honesty got the patch bounced, thanks to a policy against accepting work assisted by large language models. And wow, the comment section did not take that calmly.
The biggest fight wasn’t even about the patch itself — it was about whether the author was being punished for integrity or simply running into a rule everyone should have seen coming. One side basically yelled, “Nobody want vibecode slop” and treated any mention of AI like a giant red warning label. Another camp was furious at the framing, insisting honesty didn’t reject the patch, the maintainers did. One especially spicy commenter said they had an “exceptionally strong, visceral, negative reaction” to anyone who wasn’t offended by the arguments. Casual discussion? Absolutely not. Full drama mode? Very much yes.
Then came the more practical hot takes: some argued mentioning AI at all was a self-own, because in today’s panic-filled climate it distracts from the real work. Others suggested a velvet-rope solution — let only trusted contributors bring in AI-assisted patches, like an invite-only club for code. The meme of the day was clear: tell the truth and get branded a "vibecoder," stay quiet and maybe no one notices. That irony, more than the software patch itself, is what really set the crowd on fire.
Key Points
- •The author says they spent months analyzing Emacs performance on macOS using instrumentation, benchmarks, and repeated investigation of rendering, memory allocation, and regexp-related behavior.
- •The article states that earlier attempts to use multiple LLMs for codebase analysis produced weak results, but GLM 5.2 later generated reports the author found more useful.
- •According to the article, the author reviewed, modified, and manually tested a narrow 92-line patch before submitting it to the emacs-devel mailing list.
- •The author says the patch was rejected the next day because GNU policy does not accept LLM-assisted contributions.
- •The article includes the author’s explicit disclosure that GLM 5.2 found the issue and drafted the patch, while the author claimed legal authorship and full responsibility for the submission.