Prompt is not selectable when REQUIRE-MATCH is a function

[zeebu]

mkdir /tmp/vtest && touch /tmp/vtest/foo.elc /tmp/vtest/foo.elc.orig
In emacs -Q with vertico-mode enabled, evaluate:

(read-file-name "File: " "/tmp/vtest/" nil t) ; REQUIRE-MATCH = t

then type foo.elc and press RET.

• Vanilla Emacs: returns /tmp/vtest/foo.elc — the file you typed.
• Vertico: silently returns /tmp/vtest/foo.elc.orig — a different, wrong file.

[minad]

Yes, this happens since the *.elc file extension is filtered by completion-ignored-extensions and as such does not occur in the candidate list. Check by setting (setq completion-ignored-extensions nil). In order to still select foo.elc despite it missing from the completion list press M-RET, see the README regarding missing candidates and submitting the prompt.

However Vertico could probably do a little better here. When the input matches an ignored filename exactly, Vertico should perhaps still display it in the list. This should make the behavior more intuitive. I'll see if this is easily possible.

EDIT: Commit 5a5681e improves the behavior. Please check it out.

[catern]

The same problem happens with Info-read-node-name and read-color too. It's a bug in vertico with ACTION=lambda plus require-match=t: if the user's input is a valid completion according to ACTION=lambda, it should be allowed, and vanilla Emacs allows it but vertico does not.

[catern]

It is used by a few upstream callers: read-signal-name, list-directory, read-dir-locals-file, package-vc-checkout, vc-clone. It was added in 49e06183f59 in 2022. I did some investigation and Stefan Monnier raised the exact concern about redundancy here: https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00539.html

I see the motivation is for things like read-file-name where we
can't specify a completion table (otherwise we could also get the same
result with an appropriate completion table whose test-completion is
adjusted accordingly).

Not the best API design IMO but I guess at least there's a reason.

BTW, I think in 291280b you should be calling both test-completion and require-match; require-match doesn't override test-completion, it supplements it (at least in the default completion UI).

[minad]

Not the best API design IMO but I guess at least there's a reason.

Yes, agree, it is a reason since REQUIRE-MATCH is passed through.

BTW, I think in 291280b you should be calling both test-completion and require-match; require-match doesn't override test-completion, it supplements it (at least in the default completion UI).

Really, this API is crap! But I guess it makes sense to use it as supplement. (Added in a7ed6ce.)

[minad]

Also another problem is, as Stefan had mentioned, the potential overlap with the PREDICATE. This does not make much sense to me. One could even come to conclude that the UI should filter out candidates which do not match according to the REQUIRE-MATCH function, which might cause another inefficiency. The only scenario where this works properly is on checking free form input.

[minad]

I checked this again:

(defun completion--complete-and-exit (beg end
                                          exit-function completion-function)
  "Exit from `require-match' minibuffer.
COMPLETION-FUNCTION is called if the current buffer's content does not
appear to be a match."
  (cond
   ;; Allow user to specify null string
   ((= beg end) (funcall exit-function))
   ;; The CONFIRM argument is a predicate.
   ((functionp minibuffer-completion-confirm)
    (if (funcall minibuffer-completion-confirm
                 (buffer-substring beg end))
        (funcall exit-function)
      (unless completion-fail-discreetly
	(ding)
	(completion--message "No match"))))
   ;; See if we have a completion from the table.
   ((test-completion (buffer-substring beg end)
                     minibuffer-completion-table
                     minibuffer-completion-predicate)
    ;; FIXME: completion-ignore-case has various slightly
    ;; incompatible meanings.  E.g. it can reflect whether the user
    ;; wants completion to pay attention to case, or whether the
    ;; string will be used in a context where case is significant.
    ;; E.g. usually try-completion should obey the first, whereas
    ;; test-completion should obey the second.
    (when completion-ignore-case
      ;; Fixup case of the field, if necessary.
      (let* ((string (buffer-substring beg end))
             (compl (try-completion
                     string
                     minibuffer-completion-table
                     minibuffer-completion-predicate)))
        (when (and (stringp compl) (not (equal string compl))
                   ;; If it weren't for this piece of paranoia, I'd replace
                   ;; the whole thing with a call to do-completion.
                   ;; This is important, e.g. when the current minibuffer's
                   ;; content is a directory which only contains a single
                   ;; file, so `try-completion' actually completes to
                   ;; that file.
                   (= (length string) (length compl)))
          (completion--replace beg end compl))))
    (funcall exit-function))
   ;; The user is permitted to exit with an input that's rejected
   ;; by test-completion, after confirming her choice.
   ((memq minibuffer-completion-confirm '(confirm confirm-after-completion))
    (if (or (eq last-command this-command)
            ;; For `confirm-after-completion' we only ask for confirmation
            ;; if trying to exit immediately after typing TAB (this
            ;; catches most minibuffer typos).
            (and (eq minibuffer-completion-confirm 'confirm-after-completion)
                 (not (memq last-command minibuffer-confirm-exit-commands))))
        (funcall exit-function)
      (minibuffer-message "Confirm")
      nil))

   (t
    ;; Call do-completion, but ignore errors.
    (funcall completion-function))))

Here the require match function is used instead of test-completion as I originally had it.

[catern]

Oh you're right, my apologies, I totally misread the cond case... ugh, that's really terrible.

[zeebu]

This conversation for too into the weeds for me. I think vertico should keeps most of its current behavior. I like that it protects you against select-buffer mistakes, and should continue to default the selection to the first candidate. I just want to be able to scroll up to the prompt line and submit that whenever I want, unless 'no-prompt was configured.

…

On Thu, Aug 27, 2026, 9:04 PM Daniel Mendler ***@***.***> wrote: Okay. BTW, when REQUIRE-MATCH is a function, make sure to also call that function in the same circumstances you call test-completion. It basically serves the same purpose. Truth is, I disagree with this feature. As you are aware, it is redundant with the test-completion action, and was added later. Is this widely used? vertico-exit supports it but I only added it there begrudgingly. — Reply to this email directly, view it on GitHub <#680?email_source=notifications&email_token=AB3W5YGZEBRWTAIITFEEQFT5MDLAZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHAZDCNZXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18182177>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3W5YAGAHMTLPYWM3IITWT5MDLAZAVCNFSNUABIKJSXA33TNF2G64TZHMZTKMZXHA3DCMRRHNCGS43DOVZXG2LPNY5TCMBWHEZTSOBWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AB3W5YAJQ4K6NNFLBRVM4OD5MDLAZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHAZDCNZXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AB3W5YAKFOU6YPDA3URLV6T5MDLAZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHAZDCNZXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[minad]

@zeebu Yes, I agree. The goal was and is to preserve existing behavior, and this has been achieved. All that has been changed for now is (1) that exactly matching files are not filtered out, and (2) that you can move to the prompt if it contains a valid completion. This had not been supported for REQUIRE-MATCH=t but now it is supported. During regular usage one should not notice a significant difference to before, but the behavior in this edge case is slightly better now in my opinion.

[zeebu]

Hi Daniel I tried out the latest commit and unfortunately I'm finding this unusable. My REQUIRED-MATCH lambda communicates with an external service to check validity so calling it on every key stroke is crushing my emacs. It also reaponds to invalid input by user-erroring to give details about why it's invalid, which kills the redisplay and dumps to debug instead of being shown to the user. I think I really just want this run on submission as before, and to be able to select the prompt line if if REQUIRED-MATCH is a lambda and not 'no-prompt.

…

On Fri, Aug 28, 2026, 11:55 AM Spencer Baugh ***@***.***> wrote: Oh you're right, my apologies, I totally misread the cond case... ugh, that's really terrible. — Reply to this email directly, view it on GitHub <#680?email_source=notifications&email_token=AB3W5YBTY4WXGYNK6H7P35D5MGTPFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHEYDOOJYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18190798>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3W5YBFXA7ELX2AZGNJIKL5MGTPFAVCNFSNUABIKJSXA33TNF2G64TZHMZTKMZXHA3DCMRRHNCGS43DOVZXG2LPNY5TCMBWHEZTSOBWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AB3W5YHAF2E42UTVUVU3AUT5MGTPFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHEYDOOJYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AB3W5YH6QI2563UYXWM7XST5MGTPFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHEYDOOJYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[minad]

I see. Unfortunately the API is quite under specified. I think calling once per key press should be fine, but one can also interpret it as you did, expecting a call only in the very end when exiting the minibuffer. Try this commit: ccf9856.

[zeebu]

Thanks this works great!

…

On Thu, Sep 3, 2026, 7:10 PM Daniel Mendler ***@***.***> wrote: I see. Unfortunately the API is quite unspecified. I think calling once per key press should be fine, but one can also interpret it as you did, expecting a call only in the very end when exiting the minibuffer. Try this commit: ccf9856 <ccf9856> . — Reply to this email directly, view it on GitHub <#680?email_source=notifications&email_token=AB3W5YG5XISA27AW5XTQW6L5NH24VA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSG43TKOJXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18277597>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3W5YDWMBVH7775PLEH45L5NH24VAVCNFSNUABIKJSXA33TNF2G64TZHMZTKMZXHA3DCMRRHNCGS43DOVZXG2LPNY5TCMBWHEZTSOBWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AB3W5YGBXF7EXMBPT74VV535NH24VA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSG43TKOJXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AB3W5YHPCM3JAWBONVJ5N7L5NH24VA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSG43TKOJXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>