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.