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.
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).