Hacker News Reader

Comment by 1899-12-30 | Hacker News Reader

Is there no code review for making changes? And that patch is from feburary, why is this email drama happening only now? Genuine questions, I don't know much about emacs/gnu project development.

View on HN

Minor changes aren't reviewed very much, major changes are typically reviewed when someone posts them on the list before committing them. The author is complaining that this is a major change, it's complicated his package (a heavily used one), and the problems haven't been resolved after many months.

Enacs-lisp relies on disciplined use of a single global namespace, with extremely long names. Using names from a part of the namespace that "belongs" to someone else is rude and IMO bad.

Oh, so that's why this was so ragequit-worthy: the global elisp namespace is delicate, and unilateral changes like this without consulting the maintainer of the stomped-over package is a big no-no.

Here is some insight as to the timing:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-11/msg...

The timing and also the root issue: Alan wants the `c-mode` symbol to mean "The mode I maintain, named 'CC-mode". The (dare I say) community is moving in the direction of it meaning "The mode users want to use for C (and C++ and C-like) files" (note: IIUC, this has outsized impact on the entire emacs ecosystem because a lot of modes for c-like languages are built atop the user's c-mode to save a lot of repetition, so the c-mode is both a major mode in its own right and the support framework for several other modes).

Ultimately, "name ownership" isn't really a thing, it's going to be a lot more convenient to change one symbol's semantic meaning than to require an unknown number of additional dependent projects to remap to some other symbol, and while I respect Mr. Mackenzie's frustration, one's "ownership" is always limited when one works on free software collaboratively with others.

These names are not internal names, like identifiers in the C source code of vim. The names in question appear in lot's of users Emacs configuration files. And Emacs has been extremely reluctant to change the meaning of those names in the past. Doing it here contradicts an important expectations of long time users. This is not only about "name ownership" of some mode's maintainer.

Unless I misunderstand, the idea is that treesitter C-mode is supposed to be pretty-much a replacement for traditional c-mode, right? As in "In circumstances where I want to invoke the C-major-mode, I now want to invoke the one that uses treesitter?"

If so, shifting the interpretation of the `c-mode` symbol seems the right avenue to accomplish that goal.

No, Emacs has lots and lots of config variables and functions which depend on the exact mode used. So, if you switch the major mode, you also have to switch to other config variables and functions. And as far as I see it, c-ts-mode is far from being a drop in replacement for everyone that currently uses c-mode.

> Unless I misunderstand, the idea is that treesitter C-mode is supposed to be pretty-much a replacement for traditional c-mode, right?

you're very much mistaken.

Head of that (very long) thread containing an objection from third party Eli to code committed by the person resigning:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-11/msg...

Yeah, a basic "code ownership" check before merge would have been enough.

It reads like this is more of a bio problem than a digital problem.

That would require the use of a 21st-century development workflow.

you've misunderstood, no one is complaining about a lack of technical controls.

Reply on news.ycombinator.com