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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#66328: closed (29.1; Incompatible change to `completing-read'
 breaks existing code)
Date: Wed, 04 Oct 2023 07:32:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 04 Oct 2023 10:31:12 +0300
with message-id <83leci6dz3.fsf <at> gnu.org>
and subject line Re: bug#66328: 29.1; Incompatible change to `completing-read' breaks existing code
has caused the debbugs.gnu.org bug report #66328,
regarding 29.1; Incompatible change to `completing-read' breaks existing code
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
66328: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66328
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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 part 3 (message/rfc822, inline)]

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.