Emacs is in the process of moving from legacy languages modes using regexps and elisp for syntax analysis to new modes using tree sitter.<p>In this context, what does a name like "c-mode" should mean? Options:
1) it should stick to the old mode, cc-mode here. To use the new mode, use explicitly c-ts-mode;
2) it should move to the new tree sitter mode, c-ts-mode. To use the old mode, use explicitly cc-mode;
3) it should mean the new preferred Emacs mode, with a way for the user to take back control if they have a different preference. This preferred mode will change at some point from legacy to tree sitter.<p>The change is (3), with a move to tree sitter in Emacs 30 (to be released soon) IIUC. It makes sense to me. Saying that anyone own a name as generic as "c-mode" in an open source project just because they're first and have a long history as a contributor (thanks by the way!) seems excessive. Change of default is normal in an evolving project, and as long as it's clearly documented with a way to override (which is the case IIUC) it's fine to me. One can dislike the change, but it's impossible to please everyone anyway. Emacs users are used to adjust configuration based on their preferences.<p>I understand it can be an emotional situation for the maintainer of the legacy mode. But I don't see the need to call foul play.
patch: <a href="https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-02/msg00916.html" rel="nofollow">https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-02/msg...</a><p>I think it makes emacs prefer the "new" Treesitter based c/c++ modes ahead of the venerable c/c++-mode that is older than most posters here, maintained by the email author.
Long-time contributors are so valuable to a project. I know that in some cases progress can be impeded by entrenched thinking from entrenched project members, but I think that for a FOSS project like Emacs they're the most valuable asset, above users, code, mindshare, features.<p>You can't let someone dictate direction just because they've been around a long time, or because they've sent a lot of patches. You also can't let someone have Wikipedia-editor-like feudal authority over some area just because they feel like they own it. I get that. Outside these cases though I think whatever can be done to keep core maintainers happy and on-board is probably best for the project and best for the ecosystem.
> Try using "Emacs" or
even "free software" to mean something different, and see just how quickly you would hear back from Richard Stallman.<p>What would Stallman do is not the rubric I use for, well, anything really... But I can see how somebody who feels that way would be willing to cease to provide free labor because they believe they have lost control of something on account of it becoming too popular for them to maintain fiat authority over its use.<p>Fights between individual contributors can be so strange. I find that they frequently don't actually address the underlying issue because the underlying issue can be arbitrary and somewhat petty, and engineers don't want to think of themselves as either of those things. I once got into a long argument about folder nesting depth with a co-worker only to finally discover that the underlying issue was that I was using vs code (which tacitly penalizes you the way the UI works for shallow nesting) And he was using vim (and his configuration worked better if all of the relevant files were at the same level in the file system).<p>Once I realized the issue, I deferred to him on seniority and went about retooling my process to match to the existing process. But it took us a while to realize that was the underlying issue!
An unrelated project that has dealt with the problem at issue is Debian.<p><a href="https://wiki.debian.org/DebianAlternatives" rel="nofollow">https://wiki.debian.org/DebianAlternatives</a><p>I understand the purpose of `major-mode-remap-alist' to be setting up a similar alternatives mechanism. If you have defaults, you have to have a winner.<p>The legitimate complaint is that there is a lot of code that expects `c-mode' to bring up cc-mode and builds on that, that might get loaded as a hook on `c-mode', and this will break if that function changes. It is also legitimate to expect a little discussion when something that might make your code appear obsolete is merged. When cc-mode was the default, c-ts-mode was the alternative, and you probably want a little bit of ceremony when making the switch.<p>The annoying part is viewing ownership of the `c-mode' function as somewhat absolute because you got there first. But when you have file variables that say, "mode: c", for c-like code, but you use c-ts-mode for editing c-like stuff, you really want it to load c-ts-mode and not cc-mode.<p>Also annoying is passive-aggressively putting in a change that messes up the mechanism "to spur discussion". That doesn't seem very collegial.<p>I'm just remarking on my understanding of the discussion. I'm not an Emacs maintainer by any means, just a user.
seems like a human issue (based on <a href="https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00535.html" rel="nofollow">https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00...</a>) and a bit of process one (too easy to step on someone's shoe in emacs-devel ?)<p>wonder what's a good course of action to restore peace and good spirit here
This is a little, uh, I don't know a polite way to say it, but is the author ok?<p>If you contribute code to a free software project, people are going to use, extend, or modify it. They don't have an obligation to ask permission or even inform you. That is kind of the point.<p>I agree that the change is maybe not the most well thought out and introducing ambiguity in the meaning of a symbol is probably bad software engineering in the long term. But to call it "an act of aggression" is unhinged.<p>In meme form:<p>> contributes code to a free software project<p>> someone else touches that code<p>> suprised pikachu face