From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.bugs Subject: bug#73853: 31.0.50; Should and-let* become a synonym for when-let*? Date: Tue, 29 Oct 2024 16:21:57 +0100 Message-ID: <87ed3zndd6.fsf@bernoul.li> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39599"; mail-complaints-to="usenet@ciao.gmane.io" To: 73853@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 29 16:23:18 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1t5o3x-000A5a-Au for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Oct 2024 16:23:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5o3n-0004J4-5E; Tue, 29 Oct 2024 11:23:07 -0400 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 1t5o3i-0004IN-RK for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 11:23:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t5o3i-0000zJ-HH for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 11:23:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:From:To:In-Reply-To:References:Subject; bh=5FKaShBXI4Wv1tBf4KzvE4rj+GXQvYLzg0mIvq8ad7A=; b=LrAluoH9L9UkbHviLm4Hzncc11CxywjKQfqLadls72bfQFwzvgNF+Z/7rwGWO1EoO/IBRU96P5xHzwkgdt+zWIdqMU3BUoRL6bYB1LEuCMAIKBpIYw6oESGMJ5KZ6Jy7O2M4KoTBKIkgcpmjd0OLAUaXCWodQDD3dgA7S2YstspTt7HhemOJXTOAXgcnnXlxWFekVHtIJmH42NE420fl7SDQGaMXS3cm3fqTUgYZjlk8u/j3JNvrKg2Uh2zoeTIL9cLQ0jHMg0ShbO5lbcH7Y6LUG43jccEpK+h/SRcZUjYZGbI++MXTwdqQdFhonftZWRW3q3vqELVSHIaRwJiEJw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t5o3i-0008Vp-57 for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 11:23:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Jonas Bernoulli Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2024 15:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73853 X-GNU-PR-Package: emacs Original-Received: via spool by 73853-submit@debbugs.gnu.org id=B73853.173021532532699 (code B ref 73853); Tue, 29 Oct 2024 15:23:02 +0000 Original-Received: (at 73853) by debbugs.gnu.org; 29 Oct 2024 15:22:05 +0000 Original-Received: from localhost ([127.0.0.1]:56934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5o2m-0008VL-Lw for submit@debbugs.gnu.org; Tue, 29 Oct 2024 11:22:05 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:36840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5o2j-0008Uw-LL for 73853@debbugs.gnu.org; Tue, 29 Oct 2024 11:22:03 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id A3A1216610 for <73853@debbugs.gnu.org>; Tue, 29 Oct 2024 16:21:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :subject:subject:from:from; s=sel2011a; t=1730215319; bh=tPUyniD /HQM0Xg2ANAQgj9gHpgtFZw+DXUcOZ1W7vf0=; b=fMFYojQnNARYyEyYZP/Mv4f k2DZxsIakSHpz5JxPfNeXM7A9N14123Nsfb+E38sp2A5lXxtnomorTaJHAXJoeiQ 66G5HZAupaRmNGIZZcSHb6T//0fN0qcj7TmO+EK5OfJNpbuBT4EG5Rut/jmfwdy9 3NQXYSOP4V1aDyFq/jiM= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id qjyDv9ucNSKm for <73853@debbugs.gnu.org>; Tue, 29 Oct 2024 16:21:59 +0100 (CET) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 5EA9516400 for <73853@debbugs.gnu.org>; Tue, 29 Oct 2024 16:21:58 +0100 (CET) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:294499 Archived-At: Hello all, It is very disappointing that you have chosen to deprecate if-let and when-let in such a rushed manner. The same was done and reverted in 2018, and many of the same actors are involved this time around. I am surprised that you would make the same unforced error again. Reading through this and past conversations it is clear that there is no consensus what the ultimate goal is. But as far as I can tell, few, if any, are fully satisfied with the current (30.0.*) situation. There also seems to be agreement that unfortunate mistakes were made in the past, which limits our options now. This could have been prevented if more people (including non-debbugs and non-emacs-devel regulars) were given a chance to think about the problem and time to articulate their concerns and proposals, before facts were created. Or even if the people who did take part in past conversations had spend more time actually talking things through. The same could have been done every time the dissatisfying state of the foo-let forms was brought up again, but instead new facts were rushed at every turn. Without stopping this destructive pattern, you won't be able to fix this mess. My short-term proposal is this: - Revert the depredations and remove the news entry. Even if you later decide to go through with the deprecation after all, the "damage" done by doing, reverting and redoing a few lines is minimal. (Even so, maybe discuss it for a few days before reverting.) This would have the benefit of not needlessly alienating those package authors who currently use foo-let and would like to keep doing so, if the ultimate decision is to not go through with the deprecation after all. - Do NOT revert the changes from using foo-let to using foo-let* in Emacs itself. You might end up deciding to go through with the deprecation after all, in which case it would be unfortunate to switch thousands of lines back and forth. - Re-read past conversations. Think about what *your* ideal solutions would be (think big here). Think about what your best *feasible* solutions would be. Think about what compromises you would be willing to make. Think about what compromises you would *not* willing to make, and articulate why. Think about what others have said, and what compromises they would have to make to satisfy your position and those of others. Try to understand where they are coming from. You do not have to *agree* with their motivations, to appreciate how severe the concessions are, they would have to make to *them*, to agree to your idea of the best feasible solution and your idea of an acceptable compromise. Think in particular about whether achieving your goal/compromise, would require them to roll over and admit defeat. Consider whether sticking to the current (30.0.*) status quo, might after all be the best *compromise* we could possibly reach. - Do not have this conversation just among yourselves. Any change you make here is going to affect *many* packages and their authors and users. Actively involve the affected community. Reach out on several channels, and give people time to think about the problem and share their thoughts. I am talking months here, not weeks or even days. - In addition to thinking about the state you want to reach eventually, also think about the transition process. Should it be done in several steps, and if so, what would the consequences for package authors be? Could it be done in a way that does not force package authors to change their code multiple times? Could a variable similar in spirit to lexical-binding be a viable option? - If you think that this proposal is over the top, try to consider it from the perspective of the maintainers of external packages. Take the history of this whole saga into account. Realize that there are people who have been burned by this before and who will be upset if being forced to change their packages again, maybe in a way they see as a step backward. Even if you decide that those who disagree with you are simply wrong and/or lack good taste, consider whether it is worth alienating people over this. To help kick start an informed decision finding process I have searched the Emacsmirror (a superset of GNU ELPA + NonGNU ELPA + MELPA) for these forms: | grep pattern | hits | |---------------------+------| | "(if-let\( \|$\)" | 1853 | | "(if-let\*" | 422 | | "(when-let\( \|$\)" | 4260 | | "(when-let\*" | 1162 | | "(and-let\*" | 288 | Best regards, Jonas