unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Emacs development discussions." <emacs-devel@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: My resignation from Emacs development
Date: Sat, 23 Nov 2024 18:43:55 -0500	[thread overview]
Message-ID: <jwvbjy5r2sz.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: Zz8vQPSxPOp18LYg@MAC.fritz.box

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.




  parent reply	other threads:[~2024-11-23 23:43 UTC|newest]

Thread overview: 68+ 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-23 13:41     ` Stefan Kangas
2024-11-24  2:10     ` Tree-sitter maturity Björn Bidar
2024-11-21 13:01   ` My resignation from Emacs development Alan Mackenzie
2024-11-21 13:48     ` Eli Zaretskii
2024-11-21 14:29       ` Alfred M. Szmidt
2024-11-22  0:01         ` Po Lu
2024-11-22  7:03           ` Eli Zaretskii
2024-11-22  8:14             ` Robert Pluim
2024-11-22  8:32               ` Eli Zaretskii
2024-11-22 23:59               ` Po Lu
2024-11-23  6:39                 ` Eli Zaretskii
2024-11-21 16:29       ` Alan Mackenzie
2024-11-22  5:35     ` Adam Porter
2024-11-22  7:24       ` Madhu
2024-11-22  8:11         ` Eli Zaretskii
2024-11-22  9:26           ` Madhu
2024-11-22 12:07             ` Eli Zaretskii
2024-11-22 12:40           ` Stefan Kangas
2024-11-22 13:06           ` Alan Mackenzie
2024-11-22 13:39             ` Stefan Kangas
2024-11-22 14:25             ` Eli Zaretskii
2024-11-23 22:18           ` Andrea Corallo
2024-11-22 10:57       ` Alan Mackenzie
2024-11-22 23:19         ` Adam Porter
2024-11-22 15:36     ` Stefan Kangas
2024-11-22 17:48       ` Alan Mackenzie
2024-11-23 23:43     ` Stefan Monnier via Emacs development discussions. [this message]
2024-11-23  6:10   ` Richard Stallman
2024-11-23  7:48     ` Eli Zaretskii
2024-11-23 11:06       ` Christopher Dimech
2024-11-23 11:54         ` Eli Zaretskii
2024-11-23 12:48           ` Christopher Dimech
2024-11-23 23:59       ` Adam Porter
2024-11-21  5:59 ` Gerd Möllmann
2024-11-22 11:36   ` Alan Mackenzie
2024-11-22 11:52     ` Eli Zaretskii
2024-11-23 10:36       ` Alan Mackenzie
2024-11-23 11:31         ` Eli Zaretskii
2024-11-21 13:39 ` Andrea Corallo
2024-11-21 19:01   ` Alfred M. Szmidt
2024-11-21 19:19     ` Christopher Dimech
2024-11-21 19:47     ` Eli Zaretskii
2024-11-21 19:40 ` Jim Porter
2024-11-24  4:35   ` Richard Stallman
2024-11-21 23:57 ` Po Lu
2024-11-22 17:26 ` On committing significant and/or controversial changes (was: My resignation from Emacs development) Ihor Radchenko
2024-11-22 17:47   ` Ship Mints
2024-11-22 19:04     ` Eli Zaretskii
2024-11-24  2:35       ` On committing significant and/or controversial changes Björn Bidar
2024-11-24  4:41         ` Adam Porter
2024-11-22 19:01   ` Eli Zaretskii
2024-11-23  6:10 ` My resignation from Emacs development Richard Stallman
2024-11-23  8:50   ` Eli Zaretskii
2024-11-23  6:10 ` Richard Stallman

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=jwvbjy5r2sz.fsf-monnier+emacs@gnu.org \
    --to=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).