GNU bug report logs - #66328
29.1; Incompatible change to `completing-read' breaks existing code

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66328 in the body.
You can then email your comments to 66328 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 29.1; Incompatible change to `completing-read' breaks existing code
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 <at> 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)

Message #8 received at 66328 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 66328 <at> debbugs.gnu.org
Subject: Re: bug#66328: 29.1; Incompatible change to `completing-read'
 breaks existing code
Date: Wed, 04 Oct 2023 01:25:20 +0200

On Tue, 3 Oct 2023 22:11:41 +0000 Drew Adams <drew.adams <at> 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 <at> 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

Message #11 received at 66328 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: "66328 <at> debbugs.gnu.org" <66328 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: 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 <at> 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.

Message #14 received at 66328 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 66328 <at> debbugs.gnu.org
Subject: Re: bug#66328: 29.1;
 Incompatible change to `completing-read' breaks existing code
Date: Wed, 04 Oct 2023 10:23:04 +0300

> From: Drew Adams <drew.adams <at> 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 <at> gnu.org.  Did I
> just miss it somehow?

It was discussed here:

  https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00539.html

Message #19 received at 66328-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 66328-done <at> debbugs.gnu.org, stephen.berman <at> gmx.net
Subject: Re: bug#66328: 29.1;
 Incompatible change to `completing-read' breaks existing code
Date: Wed, 04 Oct 2023 10:31:12 +0300

> Cc: "66328 <at> debbugs.gnu.org" <66328 <at> debbugs.gnu.org>
> From: Drew Adams <drew.adams <at> 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 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.