From: Christopher Dimech <dimech@gmx.com>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: My resignation from Emacs development
Date: Wed, 20 Nov 2024 17:23:20 +0100 [thread overview]
Message-ID: <trinity-0dbc3b7e-bda7-42ad-801c-b236ba48cc30-1732119800541@3c-app-mailcom-bs01> (raw)
In-Reply-To: <Zz38jvRRsSi_6C7U@MAC.fritz.box>
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).
>
>
next prev parent reply other threads:[~2024-11-20 16:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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 5:59 ` Gerd Möllmann
2024-11-21 13:39 ` Andrea Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=trinity-0dbc3b7e-bda7-42ad-801c-b236ba48cc30-1732119800541@3c-app-mailcom-bs01 \
--to=dimech@gmx.com \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).