I’ve implemented some chaining options, e.g. user typing doc → I show document suggestion →
user clicks → .querySelector() comes afterwards.
So in this example, when I click on document I apply it to the code, but also execute startCompletion command to get next suggestion (e.g. .querySelector()). It is working fine, but I have a problem with options sorting.
I’m assuming those options get to the top because filter is set to false.
What I tried:
I put a custom type on every option I have and used it in combination with compareCompletions callback (on autocompletion config) to sort my options to the top, but problem persists.
put startCompletion in macro tasks (setTimeout 1s), also didn’t help.
In this example you can see following sequence of actions:
set “doc” content
and my option (that I expect to be in the top) is listed in the very bottom:
Interestingly, that if I’m typing “document.” I get suggestion that I expect, so seems like a problem with imperative updates only:
Also interesting that I didn’t get those “default” options after calling startCompletions for the first time (for getting document. option), so maybe if it cannot match a word before using /\w+/ regex, those options get listed? But then I wonder why they are not listed with normal typing…
There were two issues here. Firstly, keywords shouldn’t be completed at all after a . token. That’s addressed in this patch.
Secondly, there was a bug in @codemirror/autocomplete that caused it to give inappropriately high scores to options when the completion result covered no text. That wasn’t visible in typical cases where all completions matched the same range, since they’d all have that same bias, but in cases where different completion sources matched different ranges, it caused effects like what you saw (boost only affects the ordering of completions that match equally well). That is fixed by this patch.