* bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code
@ 2023-10-03 22:11 Drew Adams
2023-10-03 23:25 ` Stephen Berman
2023-10-04 7:23 ` Eli Zaretskii
0 siblings, 2 replies; 5+ messages in thread
From: Drew Adams @ 2023-10-03 22:11 UTC (permalink / raw)
To: 66328
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.
In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3448)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter CFLAGS=-O2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code
2023-10-03 22:11 bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code Drew Adams
@ 2023-10-03 23:25 ` Stephen Berman
2023-10-04 2:04 ` Drew Adams
2023-10-04 7:23 ` Eli Zaretskii
1 sibling, 1 reply; 5+ messages in thread
From: Stephen Berman @ 2023-10-03 23:25 UTC (permalink / raw)
To: Drew Adams; +Cc: 66328
On Tue, 3 Oct 2023 22:11:41 +0000 Drew Adams <drew.adams@oracle.com> wrote:
> 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://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00539.html
Steve Berman
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code
2023-10-03 23:25 ` Stephen Berman
@ 2023-10-04 2:04 ` Drew Adams
2023-10-04 7:31 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2023-10-04 2:04 UTC (permalink / raw)
To: Stephen Berman; +Cc: 66328@debbugs.gnu.org
> > 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code
2023-10-04 2:04 ` Drew Adams
@ 2023-10-04 7:31 ` Eli Zaretskii
0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2023-10-04 7:31 UTC (permalink / raw)
To: Drew Adams; +Cc: 66328-done, stephen.berman
> Cc: "66328@debbugs.gnu.org" <66328@debbugs.gnu.org>
> From: Drew Adams <drew.adams@oracle.com>
> 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.
I see no reason to revert that change, so I'm closing this bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code
2023-10-03 22:11 bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code Drew Adams
2023-10-03 23:25 ` Stephen Berman
@ 2023-10-04 7:23 ` Eli Zaretskii
1 sibling, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2023-10-04 7:23 UTC (permalink / raw)
To: Drew Adams; +Cc: 66328
> From: Drew Adams <drew.adams@oracle.com>
> Date: Tue, 3 Oct 2023 22:11:41 +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 was discussed here:
https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00539.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-10-04 7:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-03 22:11 bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code Drew Adams
2023-10-03 23:25 ` Stephen Berman
2023-10-04 2:04 ` Drew Adams
2023-10-04 7:31 ` Eli Zaretskii
2023-10-04 7:23 ` Eli Zaretskii
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).