[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66328: 29.1; Incompatible change to `completing-read' breaks existin
From: |
Drew Adams |
Subject: |
bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code |
Date: |
Wed, 4 Oct 2023 02:04:01 +0000 |
> > How did the signature of `completing-read' get changed?
> > I didn't notice any proposal or discussion about this
> > in emacs-devel@gnu.org. Did I just miss it somehow?
> >
> > It used to be that _any_ REQUIRE-MATCH value that is
> > not `t', nil, `confirm', or `confirm-after-completion'
> > behaves like `t', except that type RET doesn't exit if
> > what you type does non-null completion.
> >
> > That's no longer true if the value is a function!
> > This completely changes the behavior of `completing-read'.
> >
> > Not happy with the result, and not happy with how the
> > process - how this was done, if it wasn't discussed
> > openly in emacs-devel.
>
> There was a short discussion, after the change was made, starting here:
> https://urldefense.com/v3/__https://lists.gnu.org/archive/html/emacs-
> devel/2022-
> 06/msg00539.html__;!!ACWV5N9M2RV99hQ!Pi4vEIugzynWXlOXCj_8GVnUyeP_8Q9i9ysV
> ZwoUAmd2dc4qwMRUMS8Ce9W_d_8GAlmYBaDccZg8x2-utGVJed4B$
I see; thank you!
Yes, very ugly. And no proposal or discussion;
just Lars changing things. At least Stefan
spoke up (though not about the basic breaking
of compatibility) - after the fait accompli.
I suppose I should have guessed it was something
like that. Wish I'd have seen it at the time,
and realized what the overall effect is.
Really too bad.
The justification given: "adding a new parameter
for this use case seemed a bit overboard." So
just break what that argument has always been
about, and reuse it for something altogether
different? Sigh.