* My resignation from Emacs development
@ 2024-11-20 15:13 Alan Mackenzie
2024-11-20 15:34 ` Eli Zaretskii
` (7 more replies)
0 siblings, 8 replies; 20+ messages in thread
From: Alan Mackenzie @ 2024-11-20 15:13 UTC (permalink / raw)
To: emacs-devel
Hello, Emacs.
I'm resigning my position as Emacs contributor.
The immediate reason is that, as maintainer of CC Mode, CC Mode's
symbols, its names, were taken by Emacs and used for other purposes
without informing me, much less consulting me. That makes my position as
CC Mode maintainer here untenable.
Eli Zaretskii and I have had extensive discussions, both in public and in
private email, over the last week or so, but we have been unable to reach
any satisfactory compromise solution.
Names are important. They have power. To take somebody's/somthing's
name and misuse it is an exercise of aggression. Try using "Emacs" or
even "free software" to mean something different, and see just how
quickly you would hear back from Richard Stallman. This misuse of CC
Mode's "trademarks", the symbols `c-mode', `c++-mode', and perhaps
`c-or-c++-mode', is just such an act of aggression.
These symbols have been appropriated by Emacs to mean "the current
preferred mode for C", etc., rather than C Mode, C++ Mode etc. In
certain circumstances, in particular, in Local Variables: sections and
auto-mode-alist, there is now no longer any way unambiguously to specify
C Mode or C++ Mode. Up till recently ("\\.myc\\'" . c-mode) in
auto-mode-alist meant C Mode, and would have had the effect of
auto-loading CC Mode, if needed, and running C Mode.
The change took place in the commit for bug#69191 "New var
`major-mode-remap-defaults`, for packages". It sounds so innocent, but
is an extremely bad solution for whatever problem (unspecified in the
commit message) it was intended to solve. A major mode using it changes
the interfaces of other libraries in an uncontrolled way. This is not
good software engineering.
This bug was raised and committed by Stefan Monnier. Despite the fact
that the bug fix directly impinged upon CC Mode, and there was even a
change to cc-mode.el in the patch, he failed even to inform me. The only
two modes substantially affected by this change were ruby-mode and CC
Mode, and it is clear that Dmitry Gutov, maintainer of ruby-mode, was
aware of the change. Had I known of this proposal, I would certainly
have objected to it. Stefan is intelligent enough to have realised this,
and maybe his avoidance of open discussion was motivated by this.
Bug#69191 was a big change. In Emacs, we have a convention whereby big
changes are discussed openly on emacs-devel and a consensus reached
before the change is made. Stefan Monnier has regularly violated this
convention, possibly believing that his ideas for Emacs are so good as to
be beyond question. Any attempt to question his ideas is likely to be
met by evasive non-answers, if any response at all is forthcoming. I
could give several paragraphs worth of justification for these
assertions, but I think everybody here knows I am right.
In Emacs 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. The truly contemptuous
communication style, this evasive non-answering, seems to be regarded as
acceptable. I suggest that this change.
Stefan's habit of making big changes in Emacs without seeking consensus
is at the heart of why I am resigning. These changes have caused Emacs a
lot of damage over the years and have caused other contributors,
including me, extra work and difficulty. Stefan is a Jekyll-and-Hyde
character. On the one hand, he's a very capable hacker, and is always
ready to help others with technical questions. On the other hand, as
mentioned, he is contemptuous of the Emacs conventions, and unlike
Richard and Eli, does not have the gift of knowing what the Right Thing
is.
I strongly recommend that Stefan somehow be reigned in and required to
observe Emacs's conventions about open discussion and courteous
communication. As I mentioned, his violations of these are at the core
of why I feel unable to continue contributing to Emacs.
I will shortly be unsubscribing from emacs-devel. I intend to carry on
maintaining stand alone CC Mode, and I'm prepared to deal with any CC
Mode issues which arise in Emacs. Please post these to
bug-cc-mode@gnu.org.
It just remains to say that my respect for Eli and the other maintainers
remains undiminished, and that I wish all of them and the Emacs project
all success in the future.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
@ 2024-11-20 15:34 ` Eli Zaretskii
2024-11-20 16:23 ` Christopher Dimech
` (6 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2024-11-20 15:34 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
> Date: Wed, 20 Nov 2024 15:13:18 +0000
> From: Alan Mackenzie <acm@muc.de>
>
>
> Hello, Emacs.
>
> I'm resigning my position as Emacs contributor.
I regret very much this decision of yours, and urge you to reconsider.
Your many-year contributions to Emacs in general and to CC Mode in
particular are greatly appreciated and will be sorely missed if you
decide to go with this decision.
> Stefan's habit of making big changes in Emacs without seeking consensus
> is at the heart of why I am resigning. These changes have caused Emacs a
> lot of damage over the years and have caused other contributors,
> including me, extra work and difficulty. Stefan is a Jekyll-and-Hyde
> character. On the one hand, he's a very capable hacker, and is always
> ready to help others with technical questions. On the other hand, as
> mentioned, he is contemptuous of the Emacs conventions, and unlike
> Richard and Eli, does not have the gift of knowing what the Right Thing
> is.
I must say that I disagree with this assessment of what Stefan did in
that case, and don't find anything unbecoming in his behavior, neither
in general nor in that particular case. Yes, that change should have
been discussed more thoroughly; no, Stefan didn't do anything that
doesn't happen here every other day, and certainly didn't have any
malicious intentions when he installed that change.
> It just remains to say that my respect for Eli and the other maintainers
> remains undiminished, and that I wish all of them and the Emacs project
> all success in the future.
And the same to you. But please do reconsider.
^ permalink raw reply [flat|nested] 20+ messages in thread
* My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
2024-11-20 15:34 ` Eli Zaretskii
@ 2024-11-20 16:23 ` Christopher Dimech
2024-11-21 6:22 ` Gerd Möllmann
2024-11-21 10:29 ` Alan Mackenzie
2024-11-20 16:42 ` Alfred M. Szmidt
` (5 subsequent siblings)
7 siblings, 2 replies; 20+ messages in thread
From: Christopher Dimech @ 2024-11-20 16:23 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
The claim that using free software or its associated names constitutes
aggression is fundamentally flawed. Aggression involves hostile actions
meant to cause harm, and using names in a way not intended by their
original authors is neither violent nor malicious.
One of the key principles of free software is that software should be
modifiable, and free to use in any context. Restricting how names are
used run counter to the ethos to empower users and developers, not to
limit or control their language or expressions.
Although the approach should be reconsidered, there should be some
thoughtful conversation among the community. Avoiding tones of contempt
or disregard for the foundations laid by previous contributors.
For instance, I agree with you that ("\\.myc\\'" . c-mode) in auto-mode-alist
should mean C Mode. Although C Mode would mean the emacs preferred mode.
Still, your mode name can be changed for those who want to apply an alternative
mode. Changing the mode should be a straightforward thing.
> Sent: Thursday, November 21, 2024 at 3:13 AM
> From: "Alan Mackenzie" <acm@muc.de>
> To: emacs-devel@gnu.org
> Subject: My resignation from Emacs development
>
>
> Hello, Emacs.
>
> I'm resigning my position as Emacs contributor.
>
> The immediate reason is that, as maintainer of CC Mode, CC Mode's
> symbols, its names, were taken by Emacs and used for other purposes
> without informing me, much less consulting me. That makes my position as
> CC Mode maintainer here untenable.
>
> Eli Zaretskii and I have had extensive discussions, both in public and in
> private email, over the last week or so, but we have been unable to reach
> any satisfactory compromise solution.
>
> Names are important. They have power. To take somebody's/somthing's
> name and misuse it is an exercise of aggression. Try using "Emacs" or
> even "free software" to mean something different, and see just how
> quickly you would hear back from Richard Stallman. This misuse of CC
> Mode's "trademarks", the symbols `c-mode', `c++-mode', and perhaps
> `c-or-c++-mode', is just such an act of aggression.
>
> These symbols have been appropriated by Emacs to mean "the current
> preferred mode for C", etc., rather than C Mode, C++ Mode etc. In
> certain circumstances, in particular, in Local Variables: sections and
> auto-mode-alist, there is now no longer any way unambiguously to specify
> C Mode or C++ Mode. Up till recently ("\\.myc\\'" . c-mode) in
> auto-mode-alist meant C Mode, and would have had the effect of
> auto-loading CC Mode, if needed, and running C Mode.
>
> The change took place in the commit for bug#69191 "New var
> `major-mode-remap-defaults`, for packages". It sounds so innocent, but
> is an extremely bad solution for whatever problem (unspecified in the
> commit message) it was intended to solve. A major mode using it changes
> the interfaces of other libraries in an uncontrolled way. This is not
> good software engineering.
>
> This bug was raised and committed by Stefan Monnier. Despite the fact
> that the bug fix directly impinged upon CC Mode, and there was even a
> change to cc-mode.el in the patch, he failed even to inform me. The only
> two modes substantially affected by this change were ruby-mode and CC
> Mode, and it is clear that Dmitry Gutov, maintainer of ruby-mode, was
> aware of the change. Had I known of this proposal, I would certainly
> have objected to it. Stefan is intelligent enough to have realised this,
> and maybe his avoidance of open discussion was motivated by this.
>
> Bug#69191 was a big change. In Emacs, we have a convention whereby big
> changes are discussed openly on emacs-devel and a consensus reached
> before the change is made. Stefan Monnier has regularly violated this
> convention, possibly believing that his ideas for Emacs are so good as to
> be beyond question. Any attempt to question his ideas is likely to be
> met by evasive non-answers, if any response at all is forthcoming. I
> could give several paragraphs worth of justification for these
> assertions, but I think everybody here knows I am right.
>
> In Emacs 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. The truly contemptuous
> communication style, this evasive non-answering, seems to be regarded as
> acceptable. I suggest that this change.
>
> Stefan's habit of making big changes in Emacs without seeking consensus
> is at the heart of why I am resigning. These changes have caused Emacs a
> lot of damage over the years and have caused other contributors,
> including me, extra work and difficulty. Stefan is a Jekyll-and-Hyde
> character. On the one hand, he's a very capable hacker, and is always
> ready to help others with technical questions. On the other hand, as
> mentioned, he is contemptuous of the Emacs conventions, and unlike
> Richard and Eli, does not have the gift of knowing what the Right Thing
> is.
>
> I strongly recommend that Stefan somehow be reigned in and required to
> observe Emacs's conventions about open discussion and courteous
> communication. As I mentioned, his violations of these are at the core
> of why I feel unable to continue contributing to Emacs.
>
> I will shortly be unsubscribing from emacs-devel. I intend to carry on
> maintaining stand alone CC Mode, and I'm prepared to deal with any CC
> Mode issues which arise in Emacs. Please post these to
> bug-cc-mode@gnu.org.
>
> It just remains to say that my respect for Eli and the other maintainers
> remains undiminished, and that I wish all of them and the Emacs project
> all success in the future.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
2024-11-20 15:34 ` Eli Zaretskii
2024-11-20 16:23 ` Christopher Dimech
@ 2024-11-20 16:42 ` Alfred M. Szmidt
2024-11-20 17:04 ` tomas
` (4 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Alfred M. Szmidt @ 2024-11-20 16:42 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
I'm resigning my position as Emacs contributor.
:-( I hope you reconsider, and that Eli, Stefan and the rest of the
Emacs maintainers find a better middle ground -- CC Mode is amazing --
I too think that "c-mode" should mean CC Mode and nothing else. This
just all smells of the debacle of pcase...
Some _other_ mechanism to pick between CC Mode and c-ts-mode ... or
whatever should exist, while respecting others namespaces.
If one was to introduce a dired-ts .. and M-x dired "magically"
decides between one or the other, people would be just as angry.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
` (2 preceding siblings ...)
2024-11-20 16:42 ` Alfred M. Szmidt
@ 2024-11-20 17:04 ` tomas
2024-11-20 21:56 ` Dmitry Gutov
` (3 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: tomas @ 2024-11-20 17:04 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
On Wed, Nov 20, 2024 at 03:13:18PM +0000, Alan Mackenzie wrote:
>
> Hello, Emacs.
>
> I'm resigning my position as Emacs contributor.
[...]
I, for one, will (would?) miss you dearly :-(
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
` (3 preceding siblings ...)
2024-11-20 17:04 ` tomas
@ 2024-11-20 21:56 ` Dmitry Gutov
2024-11-21 2:28 ` Stefan Kangas
` (2 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Dmitry Gutov @ 2024-11-20 21:56 UTC (permalink / raw)
To: Alan Mackenzie, emacs-devel
Hi Alan,
On 20/11/2024 17:13, Alan Mackenzie wrote:
> I'm resigning my position as Emacs contributor.
I would be sorry to see you leave.
> This bug was raised and committed by Stefan Monnier. Despite the fact
> that the bug fix directly impinged upon CC Mode, and there was even a
> change to cc-mode.el in the patch, he failed even to inform me. The only
> two modes substantially affected by this change were ruby-mode and CC
> Mode, and it is clear that Dmitry Gutov, maintainer of ruby-mode, was
> aware of the change.
To clarify on this: I've been made aware of the change, just like other
contributors, from reading the bug#69191 submission. And from my POV it
didn't make things worse, globally - but reshaped existing problems. And
it did improve some things - like ones that I had myself submitted a
proposal previously (https://debbugs.gnu.org/68246#283), which was
collectively rejected.
To be fair, I have less of a reason to take it personally due to less
focus on particular major mode(s), and less years of tenure as well.
Speaking of other solutions, maybe you'll want to check out the patch in
the nearby thread:
https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html
That scheme could make major-mode-remap-defaults unnecessary for
c-ts-mode, or in any case remove the need for the corresponding
overrides in CC Mode. I'm not sure what migration path should be
selected, though.
Best,
Dmitry
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
` (4 preceding siblings ...)
2024-11-20 21:56 ` Dmitry Gutov
@ 2024-11-21 2:28 ` Stefan Kangas
2024-11-21 12:34 ` Tree-sitter maturity (was: My resignation from Emacs development) Peter Oliver
2024-11-21 13:01 ` My resignation from Emacs development Alan Mackenzie
2024-11-21 5:59 ` Gerd Möllmann
2024-11-21 13:39 ` Andrea Corallo
7 siblings, 2 replies; 20+ messages in thread
From: Stefan Kangas @ 2024-11-21 2:28 UTC (permalink / raw)
To: Alan Mackenzie, emacs-devel
Hi Alan,
Alan Mackenzie <acm@muc.de> writes:
> The immediate reason is that, as maintainer of CC Mode, CC Mode's
> symbols, its names, were taken by Emacs and used for other purposes
> without informing me, much less consulting me. That makes my position as
> CC Mode maintainer here untenable.
That is highly regrettable. You are a valued member of our team, and
it's sad to see you go.
> These symbols have been appropriated by Emacs to mean "the current
> preferred mode for C", etc., rather than C Mode, C++ Mode etc. In
> certain circumstances, in particular, in Local Variables: sections and
> auto-mode-alist, there is now no longer any way unambiguously to specify
> C Mode or C++ Mode. Up till recently ("\\.myc\\'" . c-mode) in
> auto-mode-alist meant C Mode, and would have had the effect of
> auto-loading CC Mode, if needed, and running C Mode.
From my point of view, we are still in early days when it comes to the
new tree-sitter modes. For starters, we do not recommend them by
default, and some language modes are also not yet ready for prime-time.
I'm not even sure that a majority of distros ship the feature in a
useful form yet, but I didn't really check.
AFAIU, the purpose of `major-mode-remap-alist` is to provide a mechanism
to respect what users want. Where there is disagrement, it concerns the
technical details of how to best achieve that, and to which extent we
should set things up automatically based on indicators such as the user
actions "running a mode", "loading a file", or "running a command".
But the feature has teething problems. My understanding was that we
agreed in Bug#74339 that the situation in Emacs 30 is already better
than in Emacs 29, and that we will continue working on this in Emacs 31.
For example, it has been suggested that we should replace the automatic
setting of `major-mode-remap-defaults` with an entirely new command like
`foo-ts-mode-prefer`, that would be used as the canonical indication
that a user wants to use the tree-sitter mode everywhere. There surely
exist other options that we could evaluate also.
For this reason, I hope that there is still room to reconsider your
decision to resign.
> Stefan's habit of making big changes in Emacs without seeking consensus
> is at the heart of why I am resigning. These changes have caused Emacs a
> lot of damage over the years and have caused other contributors,
> including me, extra work and difficulty. Stefan is a Jekyll-and-Hyde
> character. On the one hand, he's a very capable hacker, and is always
> ready to help others with technical questions. On the other hand, as
> mentioned, he is contemptuous of the Emacs conventions, and unlike
> Richard and Eli, does not have the gift of knowing what the Right Thing
> is.
This is where I have to disagree quite strongly. I find the charges
directed at Stefan Monnier both unfair and one-sided. I fail to see
which of his actions or words that could possibly warrant such a
negative interpretation, or that would justify assuming any ill intent.
I have to agree with Eli. Although it would, in hindsight, certainly
have been better to discuss these particular changes in more detail in
advance, I don't see that he has done anything very unusual or different
from what most other core contributors do on a routine basis.
I also do not appreciate where it veers into ad-hominem, such as talking
about Stefan M's character, etc. That is strictly off-topic here, as
you well know, and does not reach the usual high level of standard that
one would expect from one of your posts.
Can we please all remember that we share the same goal here; that we all
want to help advance Emacs and free software?
> I will shortly be unsubscribing from emacs-devel. I intend to carry on
> maintaining stand alone CC Mode, and I'm prepared to deal with any CC
> Mode issues which arise in Emacs. Please post these to
> bug-cc-mode@gnu.org.
>
> It just remains to say that my respect for Eli and the other maintainers
> remains undiminished, and that I wish all of them and the Emacs project
> all success in the future.
Thanks for continuing to maintain CC-mode, and likewise.
I hope that you will seriously consider the idea to reverse your
decision to quit Emacs development. It would be much better if we could
find a way where we can all continue working together. I'd suggest
giving the idea at least a couple of days to fully consider, though I'll
of course respect your decision either way.
Meanwhile, if there is anything I can do to help improve things, please
feel free to reach out. Thanks again for all your work on Emacs.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
` (5 preceding siblings ...)
2024-11-21 2:28 ` Stefan Kangas
@ 2024-11-21 5:59 ` Gerd Möllmann
2024-11-21 13:39 ` Andrea Corallo
7 siblings, 0 replies; 20+ messages in thread
From: Gerd Möllmann @ 2024-11-21 5:59 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> I will shortly be unsubscribing from emacs-devel. I intend to carry on
> maintaining stand alone CC Mode, and I'm prepared to deal with any CC
> Mode issues which arise in Emacs. Please post these to
> bug-cc-mode@gnu.org.
Thanks Alan, for everything.
Will you make a package out of cc-mode, or should one use the Hg repo?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 16:23 ` Christopher Dimech
@ 2024-11-21 6:22 ` Gerd Möllmann
2024-11-21 10:05 ` Christopher Dimech
2024-11-21 10:29 ` Alan Mackenzie
1 sibling, 1 reply; 20+ messages in thread
From: Gerd Möllmann @ 2024-11-21 6:22 UTC (permalink / raw)
To: Christopher Dimech; +Cc: Alan Mackenzie, emacs-devel
Christopher Dimech <dimech@gmx.com> writes:
> One of the key principles of free software is that software should be
> modifiable, and free to use in any context. Restricting how names are
> used run counter to the ethos to empower users and developers, not to
> limit or control their language or expressions.
Seriously?
^ permalink raw reply [flat|nested] 20+ messages in thread
* My resignation from Emacs development
2024-11-21 6:22 ` Gerd Möllmann
@ 2024-11-21 10:05 ` Christopher Dimech
2024-11-21 11:23 ` Gerd Möllmann
0 siblings, 1 reply; 20+ messages in thread
From: Christopher Dimech @ 2024-11-21 10:05 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Alan Mackenzie, emacs-devel
> Sent: Thursday, November 21, 2024 at 6:22 PM
> From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Alan Mackenzie" <acm@muc.de>, emacs-devel@gnu.org
> Subject: Re: My resignation from Emacs development
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > One of the key principles of free software is that software should be
> > modifiable, and free to use in any context. Restricting how names are
> > used run counter to the ethos to empower users and developers, not to
> > limit or control their language or expressions.
>
> Seriously?
The whole thing is about freedom, not erecting some new bureaucracy to police
how people write their projects.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 16:23 ` Christopher Dimech
2024-11-21 6:22 ` Gerd Möllmann
@ 2024-11-21 10:29 ` Alan Mackenzie
2024-11-21 12:26 ` Christopher Dimech
1 sibling, 1 reply; 20+ messages in thread
From: Alan Mackenzie @ 2024-11-21 10:29 UTC (permalink / raw)
To: Christopher Dimech; +Cc: emacs-devel
Hello, Christopher.
On Wed, Nov 20, 2024 at 17:23:20 +0100, Christopher Dimech wrote:
> The claim that using free software or its associated names constitutes
> aggression is fundamentally flawed. Aggression involves hostile actions
> meant to cause harm, and using names in a way not intended by their
> original authors is neither violent nor malicious.
There are forms of aggression which don't use fists or guns.
> One of the key principles of free software is that software should be
> modifiable, and free to use in any context. Restricting how names are
> used run counter to the ethos to empower users and developers, not to
> limit or control their language or expressions.
Fine. I put it to you that if somebody were to take the name
dimech@gmx.com and prevent it connecting up with your inbox, you would
be somewhat unhappy.
> Although the approach should be reconsidered, there should be some
> thoughtful conversation among the community. Avoiding tones of contempt
> or disregard for the foundations laid by previous contributors.
How very considerate and reasonable of you. The time for "thoughtful
conversation" around the current matter is long past. You should
perhaps address your comments to those who bypass and evade "thoughtful
conversation" at the appropriate time.
> For instance, I agree with you that ("\\.myc\\'" . c-mode) in auto-mode-alist
> should mean C Mode. Although C Mode would mean the emacs preferred mode.
> Still, your mode name can be changed for those who want to apply an alternative
> mode. Changing the mode should be a straightforward thing.
C Mode has been called that for a long time, possibly longer than you
have been called Christopher Dimech. As far as I'm concerned, it's
going to keep its name.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-21 10:05 ` Christopher Dimech
@ 2024-11-21 11:23 ` Gerd Möllmann
2024-11-21 11:40 ` Eli Zaretskii
0 siblings, 1 reply; 20+ messages in thread
From: Gerd Möllmann @ 2024-11-21 11:23 UTC (permalink / raw)
To: Christopher Dimech; +Cc: Alan Mackenzie, emacs-devel
Christopher Dimech <dimech@gmx.com> writes:
>> Sent: Thursday, November 21, 2024 at 6:22 PM
>> From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: "Alan Mackenzie" <acm@muc.de>, emacs-devel@gnu.org
>> Subject: Re: My resignation from Emacs development
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>>
>> > One of the key principles of free software is that software should be
>> > modifiable, and free to use in any context. Restricting how names are
>> > used run counter to the ethos to empower users and developers, not to
>> > limit or control their language or expressions.
>>
>> Seriously?
>
> The whole thing is about freedom, not erecting some new bureaucracy to police
> how people write their projects.
With a bit of work, I think one could make a Monty Python sketch from
that.
"I want to use that function name."
"What?"
"I want to use that function name. I have the right to."
"But it's already used for 20 years. No reasonable man would..."
"Or woman..."
"Where was I?"
"I think you were finished."
"I have the right to use that function name! I'm born free!"
"From now on, I want you all to call me Loretta"
:-)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-21 11:23 ` Gerd Möllmann
@ 2024-11-21 11:40 ` Eli Zaretskii
0 siblings, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2024-11-21 11:40 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: dimech, acm, emacs-devel
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
> Date: Thu, 21 Nov 2024 12:23:36 +0100
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Thursday, November 21, 2024 at 6:22 PM
> >> From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
> >> To: "Christopher Dimech" <dimech@gmx.com>
> >> Cc: "Alan Mackenzie" <acm@muc.de>, emacs-devel@gnu.org
> >> Subject: Re: My resignation from Emacs development
> >>
> >> Christopher Dimech <dimech@gmx.com> writes:
> >>
> >> > One of the key principles of free software is that software should be
> >> > modifiable, and free to use in any context. Restricting how names are
> >> > used run counter to the ethos to empower users and developers, not to
> >> > limit or control their language or expressions.
> >>
> >> Seriously?
> >
> > The whole thing is about freedom, not erecting some new bureaucracy to police
> > how people write their projects.
>
> With a bit of work, I think one could make a Monty Python sketch from
> that.
>
> "I want to use that function name."
> "What?"
> "I want to use that function name. I have the right to."
> "But it's already used for 20 years. No reasonable man would..."
> "Or woman..."
> "Where was I?"
> "I think you were finished."
> "I have the right to use that function name! I'm born free!"
> "From now on, I want you all to call me Loretta"
>
> :-)
This is beginning to be off-topic on this list. Please either wrap up
this sub-thread, or take it to emacs-tangents@gnu.org.
TIA
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-21 10:29 ` Alan Mackenzie
@ 2024-11-21 12:26 ` Christopher Dimech
0 siblings, 0 replies; 20+ messages in thread
From: Christopher Dimech @ 2024-11-21 12:26 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
> Sent: Thursday, November 21, 2024 at 10:29 PM
> From: "Alan Mackenzie" <acm@muc.de>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: My resignation from Emacs development
>
> Hello, Christopher.
>
> On Wed, Nov 20, 2024 at 17:23:20 +0100, Christopher Dimech wrote:
>
> > The claim that using free software or its associated names constitutes
> > aggression is fundamentally flawed. Aggression involves hostile actions
> > meant to cause harm, and using names in a way not intended by their
> > original authors is neither violent nor malicious.
>
> There are forms of aggression which don't use fists or guns.
It is not unusual for people to do so. Nobody did any harm. Some
frustration perhaps.
> > One of the key principles of free software is that software should be
> > modifiable, and free to use in any context. Restricting how names are
> > used run counter to the ethos to empower users and developers, not to
> > limit or control their language or expressions.
>
> Fine. I put it to you that if somebody were to take the name
> dimech@gmx.com and prevent it connecting up with your inbox, you would
> be somewhat unhappy.
Emacs is not my inbox. There are many things I need to get accustomed to.
The final decision has always been with the emacs maintainers. Perhaps
you could become an emacs maintainer than keeping it non-gnu.
> > Although the approach should be reconsidered, there should be some
> > thoughtful conversation among the community. Avoiding tones of contempt
> > or disregard for the foundations laid by previous contributors.
>
> How very considerate and reasonable of you. The time for "thoughtful
> conversation" around the current matter is long past. You should
> perhaps address your comments to those who bypass and evade "thoughtful
> conversation" at the appropriate time.
Right.
> > For instance, I agree with you that ("\\.myc\\'" . c-mode) in auto-mode-alist
> > should mean C Mode. Although C Mode would mean the emacs preferred mode.
> > Still, your mode name can be changed for those who want to apply an alternative
> > mode. Changing the mode should be a straightforward thing.
>
> C Mode has been called that for a long time, possibly longer than you
> have been called Christopher Dimech. As far as I'm concerned, it's
> going to keep its name.
Didn't you think something general as C Mode could produce conflicts with
an built-in emacs mode? It is customary to include a package name with
other code.
> --
> Alan Mackenzie (Nuremberg, Germany).
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Tree-sitter maturity (was: My resignation from Emacs development)
2024-11-21 2:28 ` Stefan Kangas
@ 2024-11-21 12:34 ` Peter Oliver
2024-11-21 13:01 ` My resignation from Emacs development Alan Mackenzie
1 sibling, 0 replies; 20+ messages in thread
From: Peter Oliver @ 2024-11-21 12:34 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
On Wed, 20 Nov 2024, Stefan Kangas wrote:
> From my point of view, we are still in early days when it comes to the
> new tree-sitter modes. For starters, we do not recommend them by
> default, and some language modes are also not yet ready for prime-time.
> I'm not even sure that a majority of distros ship the feature in a
> useful form yet, but I didn't really check.
It depends on what you mean by useful. In Fedora, for example, Emacs is built with Tree-sitter, but each user has to (ask Emacs to) download and compile each parser as they go along.
If any Fedora packagers read this and would like to help with packaging the parsers used by Emacs, that would be welcome. The tracking bug is https://bugzilla.redhat.com/show_bug.cgi?id=2258924
It’s also worth noting that Tree-sitter itself is somewhat immature; the developers say that until it reaches version 1.0, we should be wary of potentially unannounced incompatible changes (although they are trying harder to avoid this, over time).
--
Peter Oliver
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-21 2:28 ` Stefan Kangas
2024-11-21 12:34 ` Tree-sitter maturity (was: My resignation from Emacs development) Peter Oliver
@ 2024-11-21 13:01 ` Alan Mackenzie
2024-11-21 13:48 ` Eli Zaretskii
1 sibling, 1 reply; 20+ messages in thread
From: Alan Mackenzie @ 2024-11-21 13:01 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel
Hello, Stefan.
On Wed, Nov 20, 2024 at 20:28:58 -0600, Stefan Kangas wrote:
> Hi Alan,
> Alan Mackenzie <acm@muc.de> writes:
> > The immediate reason is that, as maintainer of CC Mode, CC Mode's
> > symbols, its names, were taken by Emacs and used for other purposes
> > without informing me, much less consulting me. That makes my position as
> > CC Mode maintainer here untenable.
> That is highly regrettable. You are a valued member of our team, and
> it's sad to see you go.
Thanks for that!
> > These symbols have been appropriated by Emacs to mean "the current
> > preferred mode for C", etc., rather than C Mode, C++ Mode etc. In
> > certain circumstances, in particular, in Local Variables: sections and
> > auto-mode-alist, there is now no longer any way unambiguously to specify
> > C Mode or C++ Mode. Up till recently ("\\.myc\\'" . c-mode) in
> > auto-mode-alist meant C Mode, and would have had the effect of
> > auto-loading CC Mode, if needed, and running C Mode.
> From my point of view, we are still in early days when it comes to the
> new tree-sitter modes. For starters, we do not recommend them by
> default, and some language modes are also not yet ready for prime-time.
> I'm not even sure that a majority of distros ship the feature in a
> useful form yet, but I didn't really check.
> AFAIU, the purpose of `major-mode-remap-alist` is to provide a mechanism
> to respect what users want. Where there is disagrement, it concerns the
> technical details of how to best achieve that, and to which extent we
> should set things up automatically based on indicators such as the user
> actions "running a mode", "loading a file", or "running a command".
> But the feature has teething problems. My understanding was that we
> agreed in Bug#74339 that the situation in Emacs 30 is already better
> than in Emacs 29, and that we will continue working on this in Emacs 31.
> For example, it has been suggested that we should replace the automatic
> setting of `major-mode-remap-defaults` with an entirely new command like
> `foo-ts-mode-prefer`, that would be used as the canonical indication
> that a user wants to use the tree-sitter mode everywhere. There surely
> exist other options that we could evaluate also.
> For this reason, I hope that there is still room to reconsider your
> decision to resign.
> > Stefan's habit of making big changes in Emacs without seeking consensus
> > is at the heart of why I am resigning. These changes have caused Emacs a
> > lot of damage over the years and have caused other contributors,
> > including me, extra work and difficulty. Stefan is a Jekyll-and-Hyde
> > character. On the one hand, he's a very capable hacker, and is always
> > ready to help others with technical questions. On the other hand, as
> > mentioned, he is contemptuous of the Emacs conventions, and unlike
> > Richard and Eli, does not have the gift of knowing what the Right Thing
> > is.
> This is where I have to disagree quite strongly. I find the charges
> directed at Stefan Monnier both unfair and one-sided. I fail to see
> which of his actions or words that could possibly warrant such a
> negative interpretation, or that would justify assuming any ill intent.
For starters: The change in the meaning of `c-mode' and `c++-mode' he
introduced in bug#69191, discussed at length in my last post. Stefan is
not stupid. He knew full well what he was doing in bypassing open
discussion about major-mode-remap-defaults.
Number 2: In late January 2024, Stefan decided to replace the customary
list form of interpreted functions with opaque atoms, because the list
form "annoyed" him. In the ensuing discussion, Richard described the
proposal as "perverse", and both Eli and I were asking questions as to
the purpose of the change. Only evasive non-answers came back. There
was certainly no consensus around the proposal. Nevertheless, Stefan
quietly committed his patch on 2024-03-11 in commit
f2bccae22bd47a2e7e0937b78ea06131711b935a. Emacs is slightly less
powerful as a result, in that macros can no longer operate on the code
of a function in a reasonable fashion.
Number 3: Stefan introduced pcase.el without any open discussion, and
proliferated it rapidly around the Emacs core, leading to confusion
around the use of ` and ,, certainly on my part. Now it can be argued
that pcase has been a success, but it could have been so much better if
it had been developed cooperatively. For years there was no adequate
doc string for `pcase', and even now the doc strings for things like
pcase-let* are woefully inadequate. Stefan is not good at documenting;
nobody can be good at everything.
Number 4: Some years ago, Stefan removed the documentation of defadvice
from the elisp manual without any discussion. Despite widespread
protest, he refused to put it back again. Quite coincidentally, he had
just written and pushed nadvice.el.
Number 5: Previously, there had been an embargo on the use of the CL
library, except at compile time. This kept the size of the Emacs Lisp
language manageable, and the language easy to understand, and made
maintainers' and beginners' lives easier. At some stage this embargo
was lifted, and the use of CL rapidly proliferated through the Emacs
core. Now, it could be argued that the facilities and expressiveness of
the CL lib outweigh these disadvantages. But it was not so argued. It
just happened. Maybe somebody else but Stefan made this change, but it
seems unlikely. Incidentally, the CL library is badly documented; most
of its functions, macros, and variables lack doc strings, and comments
are sparse indeed. For example, in cl-generic.el, there is no
description of the structures and algorithms used to implement generic
functions. "Maintainable" isn't an adjective which springs to mind for
this library.
> I have to agree with Eli. Although it would, in hindsight, certainly
> have been better to discuss these particular changes in more detail in
> advance, I don't see that he has done anything very unusual or different
> from what most other core contributors do on a routine basis.
This "be nice to everybody no matter what they do" and "always assume
the best of everybody" creates the perfect atmosphere for a monster to
flourish in. Stefan is such a monster; not all the time, not even most
of the time, but in doing the things detailed above, and other things, I
don't understand why you are defending him.
I've had continual trouble over the last ~20 years with what Stefan has
done, and how he's done it. Nobody else even comes close. As I said,
this is the root cause of why I'm leaving the Emacs team. Most of the
time, he is extremely helpful and efficient at maintaining, and I'm
grateful for all the help he has given me over the years. As I said, a
Jekyll-and-Hyde character.
> I also do not appreciate where it veers into ad-hominem, such as talking
> about Stefan M's character, etc. That is strictly off-topic here, as
> you well know, and does not reach the usual high level of standard that
> one would expect from one of your posts.
I have not come anywhere near ad hominem. It is true that many forums
degenerate into slanging matches which repel decent posters.
emacs-devel is the opposite extreme, sort of touchy-feely where nobody's
allowed to offend anybody else at all, no matter what they do, why and
how they do it. This is just as unhealthy as the the continual abuse
forums; it leads to the build up of repressed resentment.
Sometimes the truth must be told bluntly, and that is what I have tried
to do here.
> Can we please all remember that we share the same goal here; that we all
> want to help advance Emacs and free software?
> > I will shortly be unsubscribing from emacs-devel. I intend to carry on
> > maintaining stand alone CC Mode, and I'm prepared to deal with any CC
> > Mode issues which arise in Emacs. Please post these to
> > bug-cc-mode@gnu.org.
> > It just remains to say that my respect for Eli and the other maintainers
> > remains undiminished, and that I wish all of them and the Emacs project
> > all success in the future.
> Thanks for continuing to maintain CC-mode, and likewise.
Thanks!
> I hope that you will seriously consider the idea to reverse your
> decision to quit Emacs development. It would be much better if we could
> find a way where we can all continue working together. I'd suggest
> giving the idea at least a couple of days to fully consider, though I'll
> of course respect your decision either way.
I can't honestly see myself changing my mind in the space of days.
Maybe in months, or a year or two. But I would ask you and the other
maintainers to take seriously the criticisms I've made yesterday and
today.
> Meanwhile, if there is anything I can do to help improve things, please
> feel free to reach out. Thanks again for all your work on Emacs.
And thanks for the project. All in all, it's been a great project to
work on.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
` (6 preceding siblings ...)
2024-11-21 5:59 ` Gerd Möllmann
@ 2024-11-21 13:39 ` Andrea Corallo
7 siblings, 0 replies; 20+ messages in thread
From: Andrea Corallo @ 2024-11-21 13:39 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Hello, Emacs.
>
> I'm resigning my position as Emacs contributor.
>
> The immediate reason is that, as maintainer of CC Mode, CC Mode's
> symbols, its names, were taken by Emacs and used for other purposes
> without informing me, much less consulting me. That makes my position as
> CC Mode maintainer here untenable.
>
> Eli Zaretskii and I have had extensive discussions, both in public and in
> private email, over the last week or so, but we have been unable to reach
> any satisfactory compromise solution.
>
> Names are important. They have power. To take somebody's/somthing's
> name and misuse it is an exercise of aggression. Try using "Emacs" or
> even "free software" to mean something different, and see just how
> quickly you would hear back from Richard Stallman. This misuse of CC
> Mode's "trademarks", the symbols `c-mode', `c++-mode', and perhaps
> `c-or-c++-mode', is just such an act of aggression.
>
> These symbols have been appropriated by Emacs to mean "the current
> preferred mode for C", etc., rather than C Mode, C++ Mode etc. In
> certain circumstances, in particular, in Local Variables: sections and
> auto-mode-alist, there is now no longer any way unambiguously to specify
> C Mode or C++ Mode. Up till recently ("\\.myc\\'" . c-mode) in
> auto-mode-alist meant C Mode, and would have had the effect of
> auto-loading CC Mode, if needed, and running C Mode.
>
> The change took place in the commit for bug#69191 "New var
> `major-mode-remap-defaults`, for packages". It sounds so innocent, but
> is an extremely bad solution for whatever problem (unspecified in the
> commit message) it was intended to solve. A major mode using it changes
> the interfaces of other libraries in an uncontrolled way. This is not
> good software engineering.
>
> This bug was raised and committed by Stefan Monnier. Despite the fact
> that the bug fix directly impinged upon CC Mode, and there was even a
> change to cc-mode.el in the patch, he failed even to inform me. The only
> two modes substantially affected by this change were ruby-mode and CC
> Mode, and it is clear that Dmitry Gutov, maintainer of ruby-mode, was
> aware of the change. Had I known of this proposal, I would certainly
> have objected to it. Stefan is intelligent enough to have realised this,
> and maybe his avoidance of open discussion was motivated by this.
>
> Bug#69191 was a big change. In Emacs, we have a convention whereby big
> changes are discussed openly on emacs-devel and a consensus reached
> before the change is made. Stefan Monnier has regularly violated this
> convention, possibly believing that his ideas for Emacs are so good as to
> be beyond question. Any attempt to question his ideas is likely to be
> met by evasive non-answers, if any response at all is forthcoming. I
> could give several paragraphs worth of justification for these
> assertions, but I think everybody here knows I am right.
>
> In Emacs 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. The truly contemptuous
> communication style, this evasive non-answering, seems to be regarded as
> acceptable. I suggest that this change.
>
> Stefan's habit of making big changes in Emacs without seeking consensus
> is at the heart of why I am resigning. These changes have caused Emacs a
> lot of damage over the years and have caused other contributors,
> including me, extra work and difficulty. Stefan is a Jekyll-and-Hyde
> character. On the one hand, he's a very capable hacker, and is always
> ready to help others with technical questions. On the other hand, as
> mentioned, he is contemptuous of the Emacs conventions, and unlike
> Richard and Eli, does not have the gift of knowing what the Right Thing
> is.
>
> I strongly recommend that Stefan somehow be reigned in and required to
> observe Emacs's conventions about open discussion and courteous
> communication. As I mentioned, his violations of these are at the core
> of why I feel unable to continue contributing to Emacs.
>
> I will shortly be unsubscribing from emacs-devel. I intend to carry on
> maintaining stand alone CC Mode, and I'm prepared to deal with any CC
> Mode issues which arise in Emacs. Please post these to
> bug-cc-mode@gnu.org.
>
> It just remains to say that my respect for Eli and the other maintainers
> remains undiminished, and that I wish all of them and the Emacs project
> all success in the future.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
Hi Alan,
I don't have much to add as I share all Eli's and Stefan's opinions
here.
I as well don't agree with your critic of S.M. actions, but more
importantly, please assume always good faith from other Emacs developers
(as suggested here [1]). Our goal here of just making a better Emacs,
this is shared by every one, and would be a pity to loose your
contribution.
Please reconsider your position, sometimes stress and other factors can
tweak our conclusion momentary, but let's not forget our goals.
Thanks
Andrea
[1] <https://www.gnu.org/philosophy/kind-communication.html>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-21 13:01 ` My resignation from Emacs development Alan Mackenzie
@ 2024-11-21 13:48 ` Eli Zaretskii
2024-11-21 14:29 ` Alfred M. Szmidt
2024-11-21 16:29 ` Alan Mackenzie
0 siblings, 2 replies; 20+ messages in thread
From: Eli Zaretskii @ 2024-11-21 13:48 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
> Date: Thu, 21 Nov 2024 13:01:52 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> I've had continual trouble over the last ~20 years with what Stefan has
> done, and how he's done it. Nobody else even comes close.
I can only say that I completely disagree with your unfavorable (to
say the least) description of Stefan's conduct here, and regret and am
very sorry that you somehow came to these conclusions, which IMO are
very wrong.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-21 13:48 ` Eli Zaretskii
@ 2024-11-21 14:29 ` Alfred M. Szmidt
2024-11-21 16:29 ` Alan Mackenzie
1 sibling, 0 replies; 20+ messages in thread
From: Alfred M. Szmidt @ 2024-11-21 14:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, emacs-devel
> I've had continual trouble over the last ~20 years with what Stefan has
> done, and how he's done it. Nobody else even comes close.
I can only say that I completely disagree with your unfavorable (to
say the least) description of Stefan's conduct here, and regret and am
very sorry that you somehow came to these conclusions, which IMO are
very wrong.
This has been brewing for a long time and you're putting your head
into the sand Eli, Alan is utterly on point. Your comment is not
helping to mitigate the damage that has been caused in the least, and
making it worse.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: My resignation from Emacs development
2024-11-21 13:48 ` Eli Zaretskii
2024-11-21 14:29 ` Alfred M. Szmidt
@ 2024-11-21 16:29 ` Alan Mackenzie
1 sibling, 0 replies; 20+ messages in thread
From: Alan Mackenzie @ 2024-11-21 16:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Hello, Eli.
On Thu, Nov 21, 2024 at 15:48:06 +0200, Eli Zaretskii wrote:
> > Date: Thu, 21 Nov 2024 13:01:52 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > I've had continual trouble over the last ~20 years with what Stefan has
> > done, and how he's done it. Nobody else even comes close.
> I can only say that I completely disagree with your unfavorable (to
> say the least) description of Stefan's conduct here, and regret and am
> very sorry that you somehow came to these conclusions, which IMO are
> very wrong.
The five anecdotes I outlined in detail in my post to Stefan K happened
as I described. How can one avoid the conclusion I came to?
In the second of these (about Stefan M's change of interpreted functions
to opaque atoms) Richard posted to the thread five times. In one of
these posts he described the proposed change as "perverse". Stefan
ignored all five of Richard's posts, and bulldozered his change through
anyway. Richard was unhappy about the change, and you were uncertain
about it, to say the least. Stefan ignored both of you (as well as
being discourteous to me) and just ploughed ahead.
What does all this say about Stefan Monnier?
It was Stefan's commit after that thread, and the fact that nothing was
done about it, that caused me finally to lose enthusiasm for the Emacs
project. Since then, I've kept going, basically by inertia and habit.
If you want to look at this thread again, it starts with this post:
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Distinguishing `consp` and `functionp`
Date: Thu, 25 Jan 2024 18:15:48 -0500
..
One way or another, Stefan will have become aware of this thread. He's
at liberty to answer and contest all the points I've made about him. I
doubt he will do so.
Anyhow, I'm leaving. I think I've now made it abundantly clear _why_
I'm leaving.
I still wish Emacs a successful future.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2024-11-21 16:29 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
2024-11-20 15:34 ` Eli Zaretskii
2024-11-20 16:23 ` Christopher Dimech
2024-11-21 6:22 ` Gerd Möllmann
2024-11-21 10:05 ` Christopher Dimech
2024-11-21 11:23 ` Gerd Möllmann
2024-11-21 11:40 ` Eli Zaretskii
2024-11-21 10:29 ` Alan Mackenzie
2024-11-21 12:26 ` Christopher Dimech
2024-11-20 16:42 ` Alfred M. Szmidt
2024-11-20 17:04 ` tomas
2024-11-20 21:56 ` Dmitry Gutov
2024-11-21 2:28 ` Stefan Kangas
2024-11-21 12:34 ` Tree-sitter maturity (was: My resignation from Emacs development) Peter Oliver
2024-11-21 13:01 ` My resignation from Emacs development Alan Mackenzie
2024-11-21 13:48 ` Eli Zaretskii
2024-11-21 14:29 ` Alfred M. Szmidt
2024-11-21 16:29 ` Alan Mackenzie
2024-11-21 5:59 ` Gerd Möllmann
2024-11-21 13:39 ` Andrea Corallo
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).