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

Previous Next

Full log

View this message in rfc822 format

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 66187 <at> debbugs.gnu.org, philipk <at> posteo.net
Subject: bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
Date: Tue, 03 Oct 2023 22:22:05 -0700

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Since completing-read is such a fundamental part of Emacs, I doubt it
>> will be possible to change this behavior.
>
> This is only about `read-file-name' - and MUST-MATCH being allowed to be
> a function is quite new (June 2022).  If we have good reasons to change
> the behavior because we find that the case when both MUST-MATCH and
> PREDICATE are specified does not work intuitively I think it would still
> be possible to tune it a bit.
>
> But we have to know which behavior is more expected than what we
> currently have.

My original expectations:

- PREDICATE narrows the list of completion candidates
- MUST-MATCH function determines whether to accept the input

I had thought that the two arguments would work independently of one
another.  IOW, the return value of MUST-MATCH would be the only factor
that determines whether input is accepted.  If MUST-MATCH returns
non-nil, the input is unconditionally accepted, and vice versa.

> This is only about `read-file-name'

Doesn't the unexpected behavior originate in completing-read?

Joseph

Previous Next

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