dynamic completion prefers candidate to non-matching query string

[mooseyboots]

when using consult--read with dynamic completion, i find it will return the first candidate rather than the query string if the latter is changed to something that doesn't match any candidate. is that deliberate?

i tested it out using non-consult completion, but due i think to the absence of asyc delays (debounce), it seems not possible to test as candidates immediately disappear on deleting the query.

a little example:

(defun test-fun (_arg)
  '("abc" "def" "ghi" "jkl"))

(let ((consult-async-input-debounce 0.2)
      (consult-async-min-input 0))
  (consult--read (consult--dynamic-collection
                  #'test-fun)
                 :prompt "prompt: "
                 :require-match nil))

if i run this, then type say "g" to trigger the candidates, then delete "g" and type "qqq RET", "abc" (the first candidate in the list) is returned, not "qqq".

is there any way around this? sometimes a user enters a query string but wants to change it, and the new string needn't match the existing candidates. it seems to me like the query string should have precedence here.

[minad]

it seems to me like the query string should have precedence here.

I think the problem you're observing comes from async debouncing. The query string itself should never be returned. This is by design. If you want to make the query string returnable you could produce it as part of the candidates in the dynamic list.