6 ms·

My Resignation from Emacs Development

77 points by jordigh 2y ago

bananapub 2y ago
patch: https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-02/msg00916.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-02/msg... 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.
- 1899-12-30 2y ago
  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.
  - juancn 2y ago
    Yeah, a basic "code ownership" check before merge would have been enough.
    - HumblyTossed 2y ago
      It reads like this is more of a bio problem than a digital problem.
    - Kwpolska 2y ago
      That would require the use of a 21st-century development workflow.
    - bananapub 2y ago
      you've misunderstood, no one is complaining about a lack of technical controls.
  - Arnt 2y ago
    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.
    - jordigh 2y ago
      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.
      - VyseofArcadia 2y ago
        [flagged]
        Arnt 2y ago
        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.
        VyseofArcadia 2y ago
        Sorry, I should have been more clear. Not unilaterally revert, but submit a reversion patch to the mailing list for discussion.
  - projektfu 2y ago
    Here is some insight as to the timing: https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-11/msg00840.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-11/msg...
    - shadowgovt 2y ago
      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.
      - funcDropShadow 2y ago
        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.
        shadowgovt 2y ago
        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.
- gpderetta 2y ago
  I have briefly tried c++-ts-mode and it majorly clashes with clang driven indentation as provided by lsp modes (no, I'm not writing a TS config to match clang-format). I'm back to c++-mode.
  - bananapub 2y ago
    I'd say the more sensible approach is to use `aphelia` and have it invoke the real life code formatter.
    - gpderetta 2y ago
      Seems interesting, but I like to run the formatter after (almost) every keystroke.
deleted 2y ago
[deleted]
kazinator 2y ago
[flagged]
- tacitusarc 2y ago
  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.
  - shadowgovt 2y ago
    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.
    - kamaal 2y ago
      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.
    - kazinator 2y ago
      Same with Unix. There can only be one /bin/sh. Debian "alternatives" and all that.
  - kazinator 2y ago
    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.
VyseofArcadia 2y ago
This is a little, uh, I don't know a polite way to say it, but is the author ok? 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. 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. In meme form: > contributes code to a free software project > someone else touches that code > suprised pikachu face
- Y_Y 2y ago
  > 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. That's all well and good, but the objection doesn't relate to someone exercising their software freedoms, it relates to the effects on the repository. If this happened in a fork then nobody could say anything, but if it happens upstream then it messes with the maintenance and development responsibilities of previously borne by Mackenzie.
  - funcDropShadow 2y ago
    It also messes with config files of lot's of users.
- tgv 2y ago
  You can't just send a pull request to Linus replacing ioctl with some function of you own writing, certainly not when it breaks other functionality. In meme form: one simply does not walk into Mordor. And the author seems ok to me, just pissed off.
- lp0_on_fire 2y ago
  Agreed. This read to me like the person had a pre-existing axe to grind.
  - fwip 2y ago
DonHopkins 2y ago
[flagged]
- jordigh 2y ago
  You kid but back during the XEmacs days, RMS did indeed argue a lot over the names. I think jwz wanted to call the original Emacs "FSF Emacs" and RMS was like, "no, it's just Emacs, and in fact, XEmacs is also just Emacs" or something like that, I don't remember.
  - seanw444 2y ago
    I'd just like to interject for a moment. What you're refering to as Emacs, is in fact, GNU/Emacs, or as I've recently taken to calling it, GNU plus Emacs.
    - shadowgovt 2y ago
      Yes, and since `emacs` by itself is otherwise unbound to a concept, we've all done the shortcut of `(defalias 'emacs 'gnu/emacs)` in our mental .emacs files.
- Y_Y 2y ago
  Eight Mouse-corpses And Constantly Spewing?
Y_Y 2y ago
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. 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.
deleted 2y ago
[deleted]
arminiusreturns 2y ago
I hate seeing emacs and gnu people fighting like this.
- griomnib 2y ago
  A flame war written in unformatted plaintext on a public list serve actually makes me nostalgic for simpler times.
  - firefax 2y ago
    >A flame war written in unformatted plaintext on a public list serve actually makes me nostalgic for simpler times. As a vi user I'll avoid taking sides on an issue I know nothing about, but when the author stated "...there is also a convention of treating eachother with respect on the mailing lists. Sadly this convention is superficial, and seems only to mean things like not using swear words..." it hit me right in the gut. It's an issue in many OS projects. Heck, it's a problem in the larger policy world -- a similar sentiment is why I stopped doing technology policy, a childhood dream of mine.
    - shadowgovt 2y ago
      There are two kinds of respect: "Treat me like an equal" and "Treat me like I have twenty years of experience and you don't." These are not the same concept, and it's easy for people to use the same word and fail to realize they aren't the same semantics.
      - griomnib 2y ago
        I wouldn’t say those are mutually exclusive. All humans deserve respect, but a lack of respect for expertise - particularly scientific - is a major problem globally and why our “intelligent” species isn’t doing anything about climate change.
        deleted 2y ago
        [deleted]
shadowgovt 2y ago
> Try using "Emacs" or even "free software" to mean something different, and see just how quickly you would hear back from Richard Stallman. 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. 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). 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!
yaantc 2y ago
Emacs is in the process of moving from legacy languages modes using regexps and elisp for syntax analysis to new modes using tree sitter. 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. 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. 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.
- shadowgovt 2y ago
  And indeed, if anything, a project like emacs being unable to make a decision like this results in a project that slowly dies from the weight of its own history. Tree-sitter is fairly universally understood now to be "the future." While cc-mode will likely have its place for a long time (hard to beat regexes on speed, even if they break down when the input is too noisy), moving the default to the tree-sitter implementation aligns with the other language modes going to tree-sitter. For good or ill, consistency is almost certainly better than new users having to learn "Your code is parsed by tree-sitter. Oh, except your C and C++ code, unless you set this flag, because Mackenzie threw a fit in 2024. That's a fun bit of history you get to care about forever now as a user!"
- juxtapose 2y ago
  I agree with giving users control, but unfortunately I cannot agree with the move to c-ts-mode. And I cannot disagree more with associating CC mode with "legacy" when it's objectively better than the other alternative, at least currently. I don't think Emacs developers are doing users a favor in this specific case. CC Mode is extremely capable. Over the years it has developed to such a maturity that almost all needs can be satisfied, and performance has never been a problem for me. It contains very few, if any, bugs, that affect my use. On the other hand, the tree-sitter major modes are not at al production-ready to be considered as default. For one thing, the whole highlighting can break for complex macros and ifdefs. (I'd be glad to be enlightened whether it's theoretically possible to fix at all -- can you correctly highlight ifdefs without doing semantic analysis with the help of a compiler?) For another, CC mode has a feature called c-guess that can quickly analyze an existing source buffer and generate a format definition which proves extremely valuable. Alas, c-ts-mode has zero support for it. I had high hopes for tree-sitter. I turned on tree-sitter modes for all my coding when it was out, and now I have zero enabled. They still have a long way to go and I don't want to spend time debugging emacs code at work. :-) Tree-sitter is not a panacea. Fast parsing alone is not what makes a good major mode.
agumonkey 2y ago
seems like a human issue (based on https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00535.html https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00...) and a bit of process one (too easy to step on someone's shoe in emacs-devel ?) wonder what's a good course of action to restore peace and good spirit here
projektfu 2y ago
An unrelated project that has dealt with the problem at issue is Debian. https://wiki.debian.org/DebianAlternatives https://wiki.debian.org/DebianAlternatives 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. 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. 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. Also annoying is passive-aggressively putting in a change that messes up the mechanism "to spur discussion". That doesn't seem very collegial. I'm just remarking on my understanding of the discussion. I'm not an Emacs maintainer by any means, just a user.
sexyman48 2y ago
[flagged]

77 points by jordigh 2y ago

patch: https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-02/msg00916.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-02/msg... 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.

1899-12-30 2y ago
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.
- juancn 2y ago
  Yeah, a basic "code ownership" check before merge would have been enough.
  - HumblyTossed 2y ago
    It reads like this is more of a bio problem than a digital problem.
  - Kwpolska 2y ago
    That would require the use of a 21st-century development workflow.
  - bananapub 2y ago
    you've misunderstood, no one is complaining about a lack of technical controls.
- Arnt 2y ago
  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.
  - jordigh 2y ago
    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.
    - VyseofArcadia 2y ago
      [flagged]
      - Arnt 2y ago
        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.
        VyseofArcadia 2y ago
        Sorry, I should have been more clear. Not unilaterally revert, but submit a reversion patch to the mailing list for discussion.
- projektfu 2y ago
  Here is some insight as to the timing: https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-11/msg00840.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-11/msg...
  - shadowgovt 2y ago
    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.
    - funcDropShadow 2y ago
      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.
      - shadowgovt 2y ago
        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.
gpderetta 2y ago
I have briefly tried c++-ts-mode and it majorly clashes with clang driven indentation as provided by lsp modes (no, I'm not writing a TS config to match clang-format). I'm back to c++-mode.
- bananapub 2y ago
  I'd say the more sensible approach is to use `aphelia` and have it invoke the real life code formatter.
  - gpderetta 2y ago
    Seems interesting, but I like to run the formatter after (almost) every keystroke.

deleted 2y ago

[deleted]

kazinator 2y ago

[flagged]

tacitusarc 2y ago
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.
- shadowgovt 2y ago
  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.
  - kamaal 2y ago
    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.
  - kazinator 2y ago
    Same with Unix. There can only be one /bin/sh. Debian "alternatives" and all that.
- kazinator 2y ago
  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.

VyseofArcadia 2y ago

This is a little, uh, I don't know a polite way to say it, but is the author ok? 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. 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. In meme form: > contributes code to a free software project > someone else touches that code > suprised pikachu face

Y_Y 2y ago
> 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. That's all well and good, but the objection doesn't relate to someone exercising their software freedoms, it relates to the effects on the repository. If this happened in a fork then nobody could say anything, but if it happens upstream then it messes with the maintenance and development responsibilities of previously borne by Mackenzie.
- funcDropShadow 2y ago
  It also messes with config files of lot's of users.
tgv 2y ago
You can't just send a pull request to Linus replacing ioctl with some function of you own writing, certainly not when it breaks other functionality. In meme form: one simply does not walk into Mordor. And the author seems ok to me, just pissed off.
lp0_on_fire 2y ago
Agreed. This read to me like the person had a pre-existing axe to grind.
- fwip 2y ago

DonHopkins 2y ago

[flagged]

jordigh 2y ago
You kid but back during the XEmacs days, RMS did indeed argue a lot over the names. I think jwz wanted to call the original Emacs "FSF Emacs" and RMS was like, "no, it's just Emacs, and in fact, XEmacs is also just Emacs" or something like that, I don't remember.
- seanw444 2y ago
  I'd just like to interject for a moment. What you're refering to as Emacs, is in fact, GNU/Emacs, or as I've recently taken to calling it, GNU plus Emacs.
  - shadowgovt 2y ago
    Yes, and since `emacs` by itself is otherwise unbound to a concept, we've all done the shortcut of `(defalias 'emacs 'gnu/emacs)` in our mental .emacs files.
Y_Y 2y ago
Eight Mouse-corpses And Constantly Spewing?

Y_Y 2y ago

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. 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.

deleted 2y ago

[deleted]

arminiusreturns 2y ago

I hate seeing emacs and gnu people fighting like this.

griomnib 2y ago
A flame war written in unformatted plaintext on a public list serve actually makes me nostalgic for simpler times.
- firefax 2y ago
  >A flame war written in unformatted plaintext on a public list serve actually makes me nostalgic for simpler times. As a vi user I'll avoid taking sides on an issue I know nothing about, but when the author stated "...there is also a convention of treating eachother with respect on the mailing lists. Sadly this convention is superficial, and seems only to mean things like not using swear words..." it hit me right in the gut. It's an issue in many OS projects. Heck, it's a problem in the larger policy world -- a similar sentiment is why I stopped doing technology policy, a childhood dream of mine.
  - shadowgovt 2y ago
    There are two kinds of respect: "Treat me like an equal" and "Treat me like I have twenty years of experience and you don't." These are not the same concept, and it's easy for people to use the same word and fail to realize they aren't the same semantics.
    - griomnib 2y ago
      I wouldn’t say those are mutually exclusive. All humans deserve respect, but a lack of respect for expertise - particularly scientific - is a major problem globally and why our “intelligent” species isn’t doing anything about climate change.
      - deleted 2y ago
        [deleted]

shadowgovt 2y ago

> Try using "Emacs" or even "free software" to mean something different, and see just how quickly you would hear back from Richard Stallman. 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. 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). 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!

yaantc 2y ago

Emacs is in the process of moving from legacy languages modes using regexps and elisp for syntax analysis to new modes using tree sitter. 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. 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. 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.

shadowgovt 2y ago
And indeed, if anything, a project like emacs being unable to make a decision like this results in a project that slowly dies from the weight of its own history. Tree-sitter is fairly universally understood now to be "the future." While cc-mode will likely have its place for a long time (hard to beat regexes on speed, even if they break down when the input is too noisy), moving the default to the tree-sitter implementation aligns with the other language modes going to tree-sitter. For good or ill, consistency is almost certainly better than new users having to learn "Your code is parsed by tree-sitter. Oh, except your C and C++ code, unless you set this flag, because Mackenzie threw a fit in 2024. That's a fun bit of history you get to care about forever now as a user!"
juxtapose 2y ago
I agree with giving users control, but unfortunately I cannot agree with the move to c-ts-mode. And I cannot disagree more with associating CC mode with "legacy" when it's objectively better than the other alternative, at least currently. I don't think Emacs developers are doing users a favor in this specific case. CC Mode is extremely capable. Over the years it has developed to such a maturity that almost all needs can be satisfied, and performance has never been a problem for me. It contains very few, if any, bugs, that affect my use. On the other hand, the tree-sitter major modes are not at al production-ready to be considered as default. For one thing, the whole highlighting can break for complex macros and ifdefs. (I'd be glad to be enlightened whether it's theoretically possible to fix at all -- can you correctly highlight ifdefs without doing semantic analysis with the help of a compiler?) For another, CC mode has a feature called c-guess that can quickly analyze an existing source buffer and generate a format definition which proves extremely valuable. Alas, c-ts-mode has zero support for it. I had high hopes for tree-sitter. I turned on tree-sitter modes for all my coding when it was out, and now I have zero enabled. They still have a long way to go and I don't want to spend time debugging emacs code at work. :-) Tree-sitter is not a panacea. Fast parsing alone is not what makes a good major mode.

agumonkey 2y ago

seems like a human issue (based on https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00535.html https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00...) and a bit of process one (too easy to step on someone's shoe in emacs-devel ?) wonder what's a good course of action to restore peace and good spirit here

projektfu 2y ago

An unrelated project that has dealt with the problem at issue is Debian. https://wiki.debian.org/DebianAlternatives https://wiki.debian.org/DebianAlternatives 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. 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. 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. Also annoying is passive-aggressively putting in a change that messes up the mechanism "to spur discussion". That doesn't seem very collegial. I'm just remarking on my understanding of the discussion. I'm not an Emacs maintainer by any means, just a user.

sexyman48 2y ago

[flagged]