bug#68815: Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument

[Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 68815@debbugs.gnu.org,
>>  philipk@posteo.net, michael_heerdegen@web.de
>> Date: Wed, 31 Jan 2024 23:04:59 -0800
>>
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> >> Cc: 68815@debbugs.gnu.org,  Philip Kaludercic <philipk@posteo.net>,
>> >>   michael_heerdegen@web.de,  Eli Zaretskii <eliz@gnu.org>
>> >> Date: Wed, 31 Jan 2024 17:05:30 -0500
>> >>
>> >> >> Also, performance can be a concern (in many cases it makes more sense
>> >> >> to make the caller pass the unquoted name rather than force it to quote
>> >> >> the name only for PRED to unquote it).
>> >> >
>> >> > The REQUIRE-MATCH function is only called once when the user attempts to
>> >> > exit the minibuffer.  Would you please explain the performance concern?
>> >>
>> >> Oh, sorry, I got confused.  Indeed, you're wrapping the REQUIRE-MATCH
>> >> arg, not the PRED arg I was ranting about.  Duh!
>> >>
>> >> It would be OK for `emacs-29`, indeed.  Eli?  Stefan?  Any objection?
>> >
>> > I don't mind, but please note that I'm not sure there will be any
>> > further 29.x releases.
>>
>> Good to know.  What is the purpose of keeping the emacs-29 branch, then?
>
> I'm not sure we will NOT release further 29.x versions, either.  There
> could be some urgent issue that justifies another release, for
> example.
>
> My point is that the motivation for backporting improvements and fixes
> from master and for installing non-essential fixes on the release
> branch is supposed to go down, since we keep the branch active only
> for some unanticipated contingencies.

Thank you for explaining.