From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: My resignation from Emacs development Date: Thu, 21 Nov 2024 13:01:52 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15253"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 21 14:03:32 2024 Return-path: 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 ) id 1tE6qK-0003rZ-01 for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Nov 2024 14:03:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tE6pU-0006hQ-TL; Thu, 21 Nov 2024 08:02:41 -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 ) id 1tE6oq-0006Vs-12 for emacs-devel@gnu.org; Thu, 21 Nov 2024 08:02:07 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tE6on-0001Wl-9f for emacs-devel@gnu.org; Thu, 21 Nov 2024 08:01:59 -0500 Original-Received: (qmail 9114 invoked by uid 3782); 21 Nov 2024 14:01:53 +0100 Original-Received: from muc.de (p4fe1590e.dip0.t-ipconnect.de [79.225.89.14]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 21 Nov 2024 14:01:52 +0100 Original-Received: (qmail 18598 invoked by uid 1000); 21 Nov 2024 13:01:52 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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:325545 Archived-At: Hello, Stefan. On Wed, Nov 20, 2024 at 20:28:58 -0600, Stefan Kangas wrote: > Hi Alan, > Alan Mackenzie writes: > > The immediate reason is that, as maintainer of CC Mode, CC Mode's > > symbols, its names, were taken by Emacs and used for other purposes > > without informing me, much less consulting me. That makes my position as > > CC Mode maintainer here untenable. > That is highly regrettable. You are a valued member of our team, and > it's sad to see you go. Thanks for that! > > These symbols have been appropriated by Emacs to mean "the current > > preferred mode for C", etc., rather than C Mode, C++ Mode etc. In > > certain circumstances, in particular, in Local Variables: sections and > > auto-mode-alist, there is now no longer any way unambiguously to specify > > C Mode or C++ Mode. Up till recently ("\\.myc\\'" . c-mode) in > > auto-mode-alist meant C Mode, and would have had the effect of > > auto-loading CC Mode, if needed, and running C Mode. > From my point of view, we are still in early days when it comes to the > new tree-sitter modes. For starters, we do not recommend them by > default, and some language modes are also not yet ready for prime-time. > I'm not even sure that a majority of distros ship the feature in a > useful form yet, but I didn't really check. > AFAIU, the purpose of `major-mode-remap-alist` is to provide a mechanism > to respect what users want. Where there is disagrement, it concerns the > technical details of how to best achieve that, and to which extent we > should set things up automatically based on indicators such as the user > actions "running a mode", "loading a file", or "running a command". > But the feature has teething problems. My understanding was that we > agreed in Bug#74339 that the situation in Emacs 30 is already better > than in Emacs 29, and that we will continue working on this in Emacs 31. > For example, it has been suggested that we should replace the automatic > setting of `major-mode-remap-defaults` with an entirely new command like > `foo-ts-mode-prefer`, that would be used as the canonical indication > that a user wants to use the tree-sitter mode everywhere. There surely > exist other options that we could evaluate also. > For this reason, I hope that there is still room to reconsider your > decision to resign. > > Stefan's habit of making big changes in Emacs without seeking consensus > > is at the heart of why I am resigning. These changes have caused Emacs a > > lot of damage over the years and have caused other contributors, > > including me, extra work and difficulty. Stefan is a Jekyll-and-Hyde > > character. On the one hand, he's a very capable hacker, and is always > > ready to help others with technical questions. On the other hand, as > > mentioned, he is contemptuous of the Emacs conventions, and unlike > > Richard and Eli, does not have the gift of knowing what the Right Thing > > is. > This is where I have to disagree quite strongly. I find the charges > directed at Stefan Monnier both unfair and one-sided. I fail to see > which of his actions or words that could possibly warrant such a > negative interpretation, or that would justify assuming any ill intent. 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. 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. 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. 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. 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. 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. 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. > 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. I've had continual trouble over the last ~20 years with what Stefan has done, and how he's done it. Nobody else even comes close. As I said, this is the root cause of why I'm leaving the Emacs team. Most of the time, he is extremely helpful and efficient at maintaining, and I'm grateful for all the help he has given me over the years. As I said, a Jekyll-and-Hyde character. > I also do not appreciate where it veers into ad-hominem, such as talking > about Stefan M's character, etc. That is strictly off-topic here, as > you well know, and does not reach the usual high level of standard that > one would expect from one of your posts. 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. > Can we please all remember that we share the same goal here; that we all > want to help advance Emacs and free software? > > I will shortly be unsubscribing from emacs-devel. I intend to carry on > > maintaining stand alone CC Mode, and I'm prepared to deal with any CC > > Mode issues which arise in Emacs. Please post these to > > bug-cc-mode@gnu.org. > > It just remains to say that my respect for Eli and the other maintainers > > remains undiminished, and that I wish all of them and the Emacs project > > all success in the future. > Thanks for continuing to maintain CC-mode, and likewise. Thanks! > I hope that you will seriously consider the idea to reverse your > decision to quit Emacs development. It would be much better if we could > find a way where we can all continue working together. I'd suggest > giving the idea at least a couple of days to fully consider, though I'll > of course respect your decision either way. I can't honestly see myself changing my mind in the space of days. Maybe in months, or a year or two. But I would ask you and the other maintainers to take seriously the criticisms I've made yesterday and today. > Meanwhile, if there is anything I can do to help improve things, please > feel free to reach out. Thanks again for all your work on Emacs. And thanks for the project. All in all, it's been a great project to work on. -- Alan Mackenzie (Nuremberg, Germany).