Subject: bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function

From: Joseph Turner <[email-masked]>
Date: Sun, 24 Sep 2023 22:12:18 -0700

Thanks for your help!!

Michael Heerdegen <[email-masked]> writes:

> Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <[email-masked]> 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?

Yes. In emacs -Q:

(mkdir "/tmp/foo" t)
(with-temp-buffer
  (write-file "/tmp/foo/bar"))
(setq default-directory "/tmp/foo/")
(read-file-name "Clone into new or empty directory: " nil nil
                (lambda (filename)
                  (or (not (file-exists-p filename))
                      (directory-empty-p filename)))
                nil
                (lambda (filename)
                  (file-directory-p filename)))

The default prompt is "/tmp/foo/". In my Emacs (29.0.92), when I
immediately press RET, read-file-name (erroneously?) returns "/tmp/foo/"
(which exists and is not empty) instead of saying "[Match required]".

Are you able to reproduce this on your machine?

> 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/[email-masked]/T/#m224de986dcc97f23e17386fb0dd2db4a513726bf
>
> I didn't understand the "this erroneously returns the default filename"
> part.  What default filename is returned?

Does my above comment answer this question?

Thank you!!

Joseph