startCompletion behaviour on first character mismatch

I’ve observed some possibly-unexpected behaviour when using startCompletion from @codemirror/autocomplete, and I’d like to know whether this is intentional before trying to work around it.

In the “Setting Up” example, pressing < starts autocompletion, and then typing ppl filters the selections as expected. However, pressing Ctrl-Space to start autocompletion and typing ppl causes the autocompletion to close. I wonder whether it should continue to count as a “match” even if the opening < isn’t explicitly typed?

In the “Providing Completions” example, pressing Ctrl-Space starts autocompletion, then typing ag first closes the autocompletion (on the first character) then re-opens it (on the second character). This seems like it might be a bug, but again I’m not sure what’s expected to happen if the first character doesn’t match.

What happens is this:

  • The completion filter, for short inputs, will only match those that match the start of the completion
  • Thus, since all completions start with <, you won’t get any matches
  • Completion is reset when none of the active sources provide any matching results
  • Because continued typing happens in a context (plain HTML text) where it is not completed, completion isn’t reactivated

This is all intentional behavior, and I don’t think its outcome is that surprising in this case.

Firstly, I think the autocompletion works perfectly in the usual case where it opens automatically during typing. The problem is only seen when using the “startCompletion” keyboard shortcut (which I don’t personally use, but since it exists I’m trying to get it work smoothly).

The completion filter, for short inputs, will only match those that match the start of the completion

I think this might be the source of the issue. In the HTML example it makes sense when typing “<” that everything after that needs to have the prefix (and even that the autocomplete menu will close if the < is deleted), but it feels like typing Ctrl-Space then “div” should match the “<div” completion option.

This is more obvious in the second example, where typing “a” doesn’t match “magic” (and closes the autocomplete menu) but then typing a following “g” does match “magic” (and reopens the autocomplete menu).