Re: My resignation from Emacs development

[Stefan Kangas <stefankangas@gmail.com>]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

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

The patch was posted to Bug#69191 on 2024-02-16, received its first
reply on 2024-02-21 ("SGTM"), and was committed on 2024-03-03, more than
two weeks later.  That all seems bog-standard to me.

Meanwhile, the patch that you installed 1fdf0f68ccf0 was _not_ posted
anywhere before it was installed, but it turned out to be controversial.
Should you be condemned for that?  Eli didn't seem to think so when he
filed Bug#74339, and I agree.  Some questions were asked, though.

I also don't understand why anyone would have reason to suspect that you
(or anyone else, really) would find the change in Bug#69191 so
objectionable.  I would never have guessed that myself, and the
controversy therefore caught many of us by surprise.  I still find some
of the objections bewildering but would be happy to continue working to
resolve any outstanding concerns.

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

I disagree, actually.  I recall a lengthy discussion with several
participants that clarified why the change was indeed beneficial.

I spent quite some time thinking about the issue myself, and also came
to the conclusion that it was a good change, though I didn't have much
technical content to add at that point which hadn't already been
explained.

Perhaps no one pointed out that using opaque function objects as we now
do is already standard practice in both Common Lisp and Scheme; both are
clearly examples of very powerful and capable Lisp dialects.  I don't
see that this change has made Emacs any less powerful.

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

I submit that the reason why pcase has proliferated both in core and
externally is that it is fundamentally useful.  This proliferation is
not due to a master plan concocted by Stefan Monnier (who, for the
record, was an Emacs maintainer when pcase.el was installed).  I'm sure
that he did take the chance to use it to improve some existing code
though, work that we still benefit from and can be grateful for.

In practice, however, the decision to use pcase is typically made by the
person writing some piece of code, and we cannot police the style of
individual contributions on that level.  That would make no one happy,
and it would largely be detrimental to the project.  So if people like
pcase (or when-let, etc.), they will use it.

What should we blame Stefan Monnier for?  For implementing a novel
feature that has proven both highly useful and popular?

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

We routinely remove references to obsolete or deprecated functions and
macros in the manual.  There is nothing strange about that in and of
itself.  In this case, I also find nadvice.el a significant improvement
over advice.el; therefore, I think removing it was likely the right
decision.  (That said, I wasn't around at the time, so I didn't read the
discussions.)

Moreover, when nadvice.el was installed, and these changes were made in
the manual, Stefan Monnier was an Emacs maintainer.  Making such
decisions, even amid controversy, is quite literally a part of the job
description.  Our current maintainers, I'm sure, have also taken
decisions that some people have disagreed with.  C'est la vie.

We can certainly discuss changing our current development model and
decision-making process.  But for now, it is what we have.

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

You have raised this point in the past, and my impression is that few
people agree with this sweeping generalization.  I do not agree that our
current use of cl-lib constitutes a problem.

It is true that we could improve cl-lib.  It would be even better if we
added some of the more useful functions and macros to Emacs Lisp itself,
so that we would have less need for a separate library.

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

Similar to pcase, the reason cl-lib has proliferated is that many people
find it useful.  Perhaps you may need to accept that you are in the
minority on this issue.

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

Phrases such as "Jekyll-and-Hyde character", "contemptuous of the Emacs
conventions", "does not have the gift of knowing what the Right Thing
is", along with terms like "monster" and asking us "what does that say
about [him]", etc., are clearly ad hominem in my view.

These statements focus on personal characteristics rather than on
actions or statements made by an individual.

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

OK, let's be frank then.

First, I understand that there are things that you are unhappy about,
and that is valid and to be taken seriously.

However, I find your attempt to portray Stefan Monnier's character
negatively completely beyond the pale.  Using words like a "monster" to
refer to another core contributor is just appalling, and completely
uncalled for.

Thus, I am standing up for basic decency in the face of what is more and
more starting to look like an attempt at public character assassination,
using harsh language (e.g., "monster") and enumerating alleged
"mistakes" from as far back as 15 years.  I urge you to retract these
comments, and apologize.

I have already expressed my opinions on the technical issues that you
listed above.  However, from a strictly procedural standpoint, I do not
see that Stefan Monnier has exhibited a pattern of behaviour that stands
out as culpable or even unusual within our development model.

Note that I am not claiming he has never made mistakes, or that
everything he has done is perfect.  I am quite sure that he has done
many mistakes, both technical and procedural.  But so has every single
person on this list.  That does not justify singling him out, nor does
it justify the attacks directed at him here.

Please understand that the changes that Stefan Monnier has authored and
that you find objectionable, in the minds of many other hackers are
improvements.  In my view, for example, he has done tremendous work to
improve Emacs, and not least to make Emacs Lisp more powerful.  The
examples you give are some of the things that I would point to if I
wanted to demonstrate that.

---

Ultimately, all of us are volunteers who care deeply about our work.
This means that feelings can sometimes run high, and that is
understandable, because we are all human beings with different ideas,
interests, and motives.

Our team of core contributors are, despite our usually polite demeanor,
a relatively rowdy group of strong-willed, and often opinionated
individuals.  This description applies to all of us; we wouldn't be
running Emacs, let alone hack on it, if it weren't true.  We are a small
church, and it is in our best interest to collaborate.

Precisely for this reason, especially when we disagree, we must make
every effort to treat each other courteously and with respect.  This
does not mean sweeping issues under the rug, or maintaining some
superficial peace merely for appearances.  But it does mean that we have
a strong preference for discussing the specific issues at hand, and that
we ask everyone to meet a minimum standard, which we refer to as "kind
communication", when participating in Emacs development.  This is not
likely to change.

I sincerely hope that you reconsider your resignation.  It is sad to see
a capable member of our core team leave.  Regardless of what happens, I
look forward to continue collaborating with you in your capacity as CC
mode maintainer.