> Re-using these names where appropriate is merely an act of consistency.
c-mode is a function name. Changing it replaces functionality. E.g., I've got references to c-mode in my .emacs (the startup file). Those now have to be replaced/updated, or they will act weird when I open a .c file. That's not ok. If you introduce a new editor mode, it's quite normal to give it another name.
I'm actually dealing with a really frustrating effect of csharp-mode being made part of emacs itself in version 29. I use spacemacs, and their csharp layer installs the csharp-mode package.. even though it doesn't need to in emacs 29.
Now every time I open a csharp file, it opens a new buffer showing a warning that the csharp-package is redundant and to please delete it. But if I delete the package, spacemacs reinstalls it...
It is super annoying when stuff like this happens, and took some hacking to deal with. So I understand the frustration that the emacs dev is feeling right now, and it's totally his right to resign.. but at the same time I'm not sure he's dealing with this situation well.
I used to get really angry about stuff like this and honestly I almost ruined my life because of how I reacted to things I didn't like. It's not a productive way to be.
Sure, but his baby just got ripped out of his arms and given to someone else. That's bound to make you feel something after all those years of labor of love.
It's not re-using so much as renaming. The were two modes for C, one of which was the original and default, hence having the name (and associated namespace) of `c-mode`. This name was changed to point to the newer tree-sitter based mode, which was I suppose a way to mark it as the "default" but left the original mode without a unique name.
Among the many comments of praise and agreement there are several that reflect the impression I've gathered from your conduct in arguments on here, which is that you have said things in the heat of debate that are more emotion than rationality.
I don't think it's a big deal, and I'm not really interested in examining this in any greater detail.
This seems like an unnecessarily dismissive take; I’m not terribly familiar with the emacs ecosystem but the breach of protocol in committing the change and the impact on long-standing behavior seem like reasonable objections to me.
Emacs doesn't really do packages or name spacing the way most modern architectures do; symbols are exposed globally, which maximizes the ability to hook and mutate the system but also means that the top level, traditional global namespace can be contested territory between individual contributors that aren't working closely together.
I wonder how long they could go on with something like this.
There are a fair bit of features that are done better today than they were done decades back. Developer tooling has been getting better.
In fact today auto complete doesn't even mean what we had 5 years back, Same with code navigation. While sticking to backwards compatibility is good for your existing users(mostly older devs), that will also close the door for new comers.
Then don't make your exit drama about function name "trademark" nonsense?
This is also nonsense:
> Try using "Emacs" or even "free software" to mean something different, and see just how quickly you would hear back from Richard Stallman.
To hear from Richard Stallman, you have to use "GNU Emacs" for your fork or unrelated project. GNU Emacs is not the first Emacs. Before that there was Lucid Emacs. GNU Emacs forked at one point giving rise to XEmacs.
The GNU project produced a clone of Unix, using all the same names for numerous utilities like "ls", "make" and "grep", as well as countless API functions.
Stallman may not like it when some people use "free software" for free-as-in-beer, or else when others insist that copyleft software is not free, but he's not a gatekeeper of the English language.
Someone else is almost as crazy is not a good justification.
GNU Emacs is not the first Emacs, but Lucid Emacs is a fork of GNU Emacs. Lucid Emacs eventually renamed itself as XEmacs (the "X" meaning "something" because they didn't know who owns the trademark as Lucid Inc went out of business.
this take is dumb, perhaps because you're not familiar with emacs? it's a lisp machine where everything gets loaded in and stumbles around in one big global namespace, social coordination, not technical controls, is used to stop them messing with each other, and in this case it didn't happen.
the patch being complained about more or less unilaterally deprecated the extremely well-established C and C++ modes written by the email's author.
Namespaces won't solve the problem. If you have namespaces/packages you can have foo:c-mode and bar:c-mode.
But if you're always using the qualified names, they are not better than just prefixes like foo-c-mode and bar-c-mode. The point of packages is that you can set up a context where you can just use c-mode, which is one of those two: either foo:c-mode or bar:c-mode. Somehow that selection has to be made, and there it's possible to continue to have arguments and drama: which one should be the default one in a vanilla installation? Or do we barrage the user with a flurry of questions to resolve each such a conflict?
When the installation is complete, and the user opens a .c or .cc file, it has to be handled by a mode which is chosen somehow from among the alternatives.
Maybe how it should work is that the first time the user opens a .c file (or other related suffix) they get prompted for which mode they would like to handle it with. The choice is then remembered, but with the option not to remember ("just this once"). Gee, either I've seen that before or I'm a UX visionary.
Deleting other people's code/features is always a point of friction in any code base, not just open source.
People deeply care about watching their work survive and be used for eternity, and when they watch their work get deleted, or replaced they generally feel someone is going after their place.
Unfortunately this often goes against how progress works. If the state of affairs has to improve, newer things have to replace older things.
Emacs is just one of those things that can't move on because its existing users expect not only backwards compatibility, but the tool remain relevant to advanced users. Im guessing any change would evoke such a response.
