From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Stefan Monnier via "Emacs development discussions." <emacs-devel@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: My resignation from Emacs development
Date: Sat, 23 Nov 2024 18:43:55 -0500
Message-ID: <jwvbjy5r2sz.fsf-monnier+emacs@gnu.org>
References: <Zz38jvRRsSi_6C7U@MAC.fritz.box>
 <CADwFkmmnxbZwp4V_4WaPvUDN9Zu+QnHBxyA6EKa-BpoctKVwCw@mail.gmail.com>
 <Zz8vQPSxPOp18LYg@MAC.fritz.box>
Reply-To: Stefan Monnier <monnier@iro.umontreal.ca>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="4169"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
To: emacs-devel@gnu.org
Cancel-Lock: sha1:pbeS6sNmjFQe+XUvmfK9JIe1FyE=
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 24 00:45:04 2024
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane-mx.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1tEzoG-0000zy-OL
	for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Nov 2024 00:45:04 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1tEznN-00068Y-Kv; Sat, 23 Nov 2024 18:44:09 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ged-emacs-devel@m.gmane-mx.org>)
 id 1tEznM-00068A-0X
 for emacs-devel@gnu.org; Sat, 23 Nov 2024 18:44:08 -0500
Original-Received: from ciao.gmane.io ([116.202.254.214])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ged-emacs-devel@m.gmane-mx.org>)
 id 1tEznK-0001o3-6W
 for emacs-devel@gnu.org; Sat, 23 Nov 2024 18:44:07 -0500
Original-Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <ged-emacs-devel@m.gmane-mx.org>) id 1tEznG-00008n-RO
 for emacs-devel@gnu.org; Sun, 24 Nov 2024 00:44:02 +0100
X-Injected-Via-Gmane: http://gmane.org/
Received-SPF: pass client-ip=116.202.254.214;
 envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io
X-Spam_score_int: -15
X-Spam_score: -1.6
X-Spam_bar: -
X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.devel:325637
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/325637>

Hi Alan,

[ Someone just made me aware of this ... interesting thread.  ]

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

Actually, I must admit that in this specific case you caught me by
surprise.  The change of meaning was fundamentally introduced AFAICT by
`major-mode-remap-alist` (for which I also plead guilty) back in
Emacs-29.  I saw it as mostly a cleanup, and I expected you'd be rather
favorable to that change.  I still can't understand what it is that
bothers you so much there and that didn't bother you in Emacs-29's
`major-mode-remap-alist`.

[ I'm no fan of the way loading files like `c-ts-mode.el` (and now
  `cc-mode.el` as well) changes the behavior of Emacs.  The patch for
  bug#69191 did not fundamentally change that (because Emacs maintainers
  had already made it clear they did not intend to accept such
  a change), and the purpose was solely to make those changes cleaner.

  E.g. previously the fact that `c-ts-mode` becomes preferred after
  loading `c-ts-mode.el` was limited to those files whose mode is chosen
  via `auto-mode-alist` rather than other methods like file-local
  cookies.
  Also, undoing that change was somewhat complicated.  ]

> Number 3: Stefan introduced pcase.el without any open discussion, and

Thanks.  Sometimes I feel like my years as Emacs contributor have been
spent doing nothing else than janitorial work, so it's good to be
reminded that I also did make some more significant contributions.

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

"coincidentally" is wrong here: the removal was made very much
explicitly in relation to the addition of `nadvice.el`, with the
explicit purpose to discourage the use of `defadvice` in new code in
favor of the new nadvice functions.  And an important reason why I was
comfortable removing that doc is because virtually the same text was
(and still is) available in the `Commentary:` section of `advice.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.

That's an opinion, not a fact.  It made some things easier, and
others harder.  Who benefited most and who suffered most is hard
to tell.  I don't think anyone here really knows.

BTW, things like pushing for the eventual removal of `defadvice` is done
for the purpose of keeping the language smaller to make maintainers' and
beginners' lives easier.  The transient state is worse, admittedly.
If Emacs dies soon, it was clearly the wrong call.  I made the decision
based on the assumption that it will live for many more years.

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

I plead guilty to turning CL into CL-lib so that it can be used at
run-time.  No doubt about that.  This was the best compromise I could
find to satisfy the constant complaints about not being able to use the
CL library in core Emacs code.

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

[ Despite its name, `cl-generic.el` is not part of CL-lib.  ]

BTW, you forgot lexical-binding in your list of my accomplishments.

You can return to regularly scheduled Lisp hacking now.


        Stefan


PS: Oh, I think I saw a mention of `if-let` in this thread, so I want
    to state clearly that I do *not* plead guilty for this one.  I'm not
    a big fan of these `if/when/while/and-let` and can't remember taking
    part in their development at all, except recently trying
    (unsuccessfully) to get rid of `and-let*`, and advocating for the
    reduction in the number of those macros.