From: Alan Mackenzie <acm@muc.de>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: My resignation from Emacs development
Date: Thu, 21 Nov 2024 13:01:52 +0000 [thread overview]
Message-ID: <Zz8vQPSxPOp18LYg@MAC.fritz.box> (raw)
In-Reply-To: <CADwFkmmnxbZwp4V_4WaPvUDN9Zu+QnHBxyA6EKa-BpoctKVwCw@mail.gmail.com>
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).
next prev parent reply other threads:[~2024-11-21 13:01 UTC|newest]
Thread overview: 20+ 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
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 ` Alan Mackenzie [this message]
2024-11-21 13:48 ` My resignation from Emacs development 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
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=Zz8vQPSxPOp18LYg@MAC.fritz.box \
--to=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=stefankangas@gmail.com \
/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).