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.
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.
Reverting would also be rude there. Their project culture assumes that you discuss on the list first. He couldn't very well commit without discussion when he's complaining that that other guy commits without discussion.
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.
