GNU bug report logs - #68815
Unexpected behavior with read-file-name and functional REQUIRE-MATCH argument

Previous Next

Full log

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, philipk <at> posteo.net, 68815 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#68815: Unexpected behavior with read-file-name and
 functional REQUIRE-MATCH argument
Date: Thu, 01 Feb 2024 14:26:18 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 68815 <at> debbugs.gnu.org,
>>  philipk <at> posteo.net, michael_heerdegen <at> web.de
>> Date: Wed, 31 Jan 2024 23:04:59 -0800
>>
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> >> Cc: 68815 <at> debbugs.gnu.org,  Philip Kaludercic <philipk <at> posteo.net>,
>> >>   michael_heerdegen <at> web.de,  Eli Zaretskii <eliz <at> 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.

Previous Next

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