Re: [NonGNU ELPA] New package: tabspaces

Here is my report based on what I have found.

I have been looking into the tabspaces package that Colin McLear
submitted to NonGNU ELPA. What I found raises serious questions about
the integrity of the contribution process.

The package tabspaces.el is a sophisticated Emacs Lisp library with
over 1,300 lines of code. The author claims to have used Claude for
bug-hunting and testing only. The commit history tells a different
story.

Let me show you what I found by examining the public git repository.

The package has 106 commits total. 

git log --oneline tabspaces.el | wc -l
106

Over four years of development, from 2022 to 2026, the normal pattern
was small incremental changes. Most commits added only a few
lines. The largest commit before July 2026 was 111 lines added.

Then on July 31, 2026, everything changed.

On that single day, the author made four commits to tabspaces.el. The
first at 10:33 added 167 insertions and 164 deletions. The second at
10:56 added 25 insertions and 15 deletions. The third at 17:26 added
274 insertions and 24 deletions. The fourth at 21:25 added 25
insertions and 20 deletions.

That is 491 insertions and 223 deletions, for a total of 714 lines
changed in one day.

What was in these commits? The messages say they added a complete
session security system with a restricted reader to prevent code
execution, author added twelve ERT tests, terminal handlers for vterm,
idle-timer auto-save, large sections rewritten.

All that would take normally days or weeks.

Every single one of these commits includes a Claude-Session link. The
author is using Claude, clearly. 

But the claim that it was only for bug-hunting and testing does not
match the evidence.

The Claude-Session links are private. They resolve to nothing for
anyone else and there is no audit trail. Only the author can see what
actually happened in those sessions. For outsiders, it is a black box.

I also looked at the author's other packages. Bibtex-capf.el has 150
lines of code. Citar-capf.el is similarly small. These packages show
normal human development patterns. Small codebases. Normal commit
histories. No massive code dumps.

Only tabspaces shows this pattern. A complex 1,300-line codebase
appearing largely in one day. Perfectly consistent style throughout
with every function with complete docstring, complete error handling
everywhere, template patterns repeated identically wich is all
characteristic of LLM-generated code.

I am not accusing anyone of lying. I am pointing out that the process
itself is opaque. We have no way to verify what was human-written and
what was generated. The author says one thing. The evidence suggests
another.

When I raised these concerns on the emacs-tangents mailing list, I was
moderated. Eli Zaretskii set my moderate flag to on and said
congratulations with obvious sarcasm. He said discussions about trust
have no place on public forums.

Isn't the trust what free software is about?

But emacs-tangents is the off-topic list. It exists precisely for
discussions that do not fit elsewhere. I was exactly where I was
supposed to be. Moderating me for using the off-topic list to discuss
an off-topic subject sends a clear message. There is no acceptable
forum for raising concerns about LLM contributions, process
transparency, or the erosion of trust in Emacs development.

The underlying issue remains unaddressed. LLM-generated code is being
accepted without clear disclosure on self-certification. There are no
established guidelines. There is no transparent procedure for
identifying or reviewing such contributions. Authors can self-certify
that they only used LLM for bug-hunting while committing hundreds of
lines of generated code in a single day.

The solution is not to silence discussion but to create clear policies
and to require disclosure of LLM use, public audit trails, to
establish review procedures and to be transparent about what is being
accepted and how.

Until then, trust will continue to erode, not because anyone is
dishonest, but because public cannot know. The process does not
provide the assurances it once did.

I have documented all of this in detail and anyone can verify what I
found in git repository.

If I am wrong, I am happy to be corrected. If I am right, the problem
is real and needs to be addressed. But that cannot happen if the
discussion is silenced and those who raise concerns are moderated with
sarcastic congratulations.


Jean Louis