Re: My resignation from Emacs development

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

Thanks for the detailed reply.

On Fri, Nov 22, 2024 at 10:36:23 -0500, Stefan Kangas wrote:
> 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.

For a big change that changes the way people work with Emacs?

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

Yes, actually, I think I should.  It was a bad idea, that idea being to
attract attention to the patch for bug#69191, and it failed miserably.
It took well over five months before Eli noticed.  I really ought to
have raised the issue in emacs-devel.

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

It enabled and encouraged software libraries to make uncontrolled
changes to other libraries' interfaces, in particular to hi-jack them.
This is just a Bad Thing.  In particular, it changed the symbols
`c-mode' and `c++-mode' from meaning, unambiguously, C Mode and C++
Mode, to meaning something else.  How can that not be controversial?

> > 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 looked at the thread closely last night.  There was no clarification
at all.  The matter was left hanging in the air with unanswered
questions.

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

Somebody did point out its presence in other Lisps, yes.  Nobody gave a
compelling reason why it would be good for Emacs Lisp.  The change broke
an old macro in CC Mode, which luckily wasn't being used for much.  I
was able to fix that.

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

I don't doubt its usefulness.  However, it could have been better if it
had been openly discussed, possibly engaging help in documenting it
better.

I don't recall any other contributer, maintainer or not, making such
large changes without consultation.

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

I don't recall any discussion over the introduction of when-let, etc.
Maybe there was.  There has recently been a long thread in emacs-devel
showing how confusing contributers have found it.

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

For doing so without open discussion on emacs-devel.

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

The feature was in widespread use throughout Emacs and external
libraries.  The documentation was still needed.  defadvice had never
been marked as deprecated up till that point.

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

No other maintainer, that I'm aware of, has made big changes to Emacs
without public discussion first.  Eli doesn't do it, you don't, and I'm
sure Andrea doesn't either.

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

That is what I have been urging you (plural) to do for a few days, now.

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

When I was actively trying to implement bug#67455 (getting function
names into backtraces where there is currently only an anonymous hex
address) the widespread use of cl-lib probably slowed my progress by a
factor of two.  I was continually having to look up (usually
non-existent) doc strings, and spent much time crawling through cl-lib
source code working out what functions did.

The last time we talked about the use of cl-lib, the discussion was
terminated by somebody (I can't remember who) undertaking to document
cl-lib.  I don't think anything ever came from that intention.

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

Again, we don't and cannot know.  There was no discussion where people
could have raised objections.  My own impression is that cl-lib does not
help contributers express things better; only differently.  But the
people who write cl-lib constructs are often not those who have to
maintain them, and those maintainers are denied the choice.

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

No.  Ad hominem has a very specific meaning.  It means attacking the
author of some writing or act in place of criticising the writing or act
itself.  It does not mean simple denigration, or even insult.
Everything I've written here is about what Stefan has DONE, together
with speculation as to why.

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

They do, yes.  You haven't commented explicitly on whether or not they
are true.

To the five anecdotes I've described, you have given a different
justification for each one.  Taken individually, each of them could
easily hold.  Taken together, they point with high probability to there
being a problem in Stefan's approach.

Maybe you could explain why I have had no such problems with any other
contributors or maintainers.  Not with you, not with Andrea, not with
Eli, despite having had quite a few disagreements with him over the
years.

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

I think you've changed my meaning somewhat by taking these phrases out
of context.

I was quite explicit about my view of Stefan; he is mostly a positive
force on Emacs, but has negative attributes, too.  I think you (plural)
are trying to pretend these negative bits don't exist, or don't matter.

> 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 think the important factor is whether or not my assertions are true.
What would I have to gain by such a character assassination?

If they are true, then I have nothing to apologise for.  If they are
mistaken, I would indeed apologise.  Quite a few posters on this thread,
and several by private email, have said they recognise that what I have
written has a basis in fact.

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

Do you have any other explanation as to why I should be so dissatisfied
that I am leaving the project?

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

No.  Stefan M is different from all other maintainers, as I have pointed
out at great length.

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

I agree with the above paragraph, mostly.  Stefan has done a lot
positive as well.

> ---

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

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).