GNU bug report logs - #66187
read-file-name unexpected behavior when MUSTMATCH is a function

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "michael_heerdegen <at> web.de" <michael_heerdegen <at> web.de>,
 "philipk <at> posteo.net" <philipk <at> posteo.net>,
 "66187 <at> debbugs.gnu.org" <66187 <at> debbugs.gnu.org>,
 "joseph <at> breatheoutbreathe.in" <joseph <at> breatheoutbreathe.in>
Subject: RE: [External] : bug#66187: read-file-name unexpected behavior when
 MUSTMATCH is a function
Date: Fri, 6 Oct 2023 14:08:51 +0000

> (we've had `require-match` for more than 30 years
> and it's only last year that we decided it was
> worth generalizing it to a function)
        ^^^^^^^^^^^^

It was decided with very little discussion, FWIW.

The 29.1 behavior is not at all more general than
the longstanding previous behavior.  Just the
opposite.  It confuses different things, co-opting
the REQUIRE-MATCH behavior with completion behavior.

All code that previously might have passed a
function value for REQUIRE-MATCH expects that value
to be treated as any other non-`nil', non-`t',
non-`confirm*' value.  That's now broken.  That more
general behavior is lost - a function value being
treated differently imposes a limitation - the
behavior is more specific now (another case added),
not more general.

The new behavior that was cobbled together into the
REQUIRE-MATCH arg should have been provided in some
other way - whether an additional arg, or a non-arg
variable, or whatever.  It should not have been
jammed into REQUIRE-MATCH, changing its behavior in
an incompatible way.

(Just one opinion.)

Previous Next

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