From: Jonas Bernoulli <jonas@bernoul.li>
To: 73853@debbugs.gnu.org
Subject: bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?
Date: Tue, 29 Oct 2024 16:21:57 +0100 [thread overview]
Message-ID: <87ed3zndd6.fsf@bernoul.li> (raw)
In-Reply-To: <jwv4j5aeltw.fsf@iro.umontreal.ca>
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
next prev parent reply other threads:[~2024-10-29 15:21 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 16:27 bug#73853: 31.0.50; and-let* is useless Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-17 16:40 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 2:11 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-18 23:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19 3:50 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-21 7:07 ` Augusto Stoffel
2024-10-21 8:57 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-21 12:09 ` Sean Whitton
2024-10-19 3:38 ` Sean Whitton
2024-10-20 12:24 ` Stefan Kangas
2024-10-22 14:47 ` bug#73853: 31.0.50; Should and-let* become a synonym for when-let*? Sean Whitton
2024-10-22 15:24 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-23 14:05 ` Stefan Kangas
2024-10-24 8:51 ` Sean Whitton
2024-10-25 12:09 ` Sean Whitton
2024-10-30 9:42 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-26 19:25 ` Jim Porter
2024-10-27 7:08 ` Stefan Kangas
2024-10-27 9:16 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 10:12 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 11:24 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 11:32 ` Sean Whitton
2024-10-27 11:44 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 12:28 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 13:10 ` Sean Whitton
2024-10-27 13:22 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 9:39 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 14:41 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 13:58 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 14:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-27 20:00 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 2:15 ` Howard Melman
2024-10-28 3:19 ` Sean Whitton
2024-10-29 15:21 ` Jonas Bernoulli [this message]
2024-10-29 16:36 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-30 0:49 ` Sean Whitton
2024-10-30 12:55 ` Corwin Brust
2024-10-30 23:10 ` Stefan Kangas
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=87ed3zndd6.fsf@bernoul.li \
--to=jonas@bernoul.li \
--cc=73853@debbugs.gnu.org \
/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).