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

Previous Next

Full log

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: "Philip Kaludercic \(Emacs\)" <philipk <at> posteo.net>, 66187 <at> debbugs.gnu.org,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#66187: read-file-name unexpected behavior when MUSTMATCH is
 a function
Date: Mon, 25 Sep 2023 05:58:01 +0200

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

> Would someone kindly explain the intended behavior here?

I don't know, but I would expect that when the MUST-MATCH predicate
fails the behavior is the same as with MUST-MATCH t, and when it
succeeds, the behavior is like MUST-MATCH nil.  Quite simple I think.
Do you see something different?

Hmm - or, maybe the confusion is about the behavior for the members of
the collection?  With other words, whether the argument can be used to
restrict which existing files are matched, vs. whether it can only be
used to limit what additionally matches?  AFAIU the latter is the case -
existing files always match.

> This issue originally came up in this thread about package-vc-checkout:
> https://yhetil.org/emacs-bugs/87v8bzi7iz.fsf <at> breatheoutbreathe.in/T/#m224de986dcc97f23e17386fb0dd2db4a513726bf

I didn't understand the "this erroneously returns the default filename"
part.  What default filename is returned?

Michael.

Previous Next

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