Context:
I’m extending javascript completion source with my custom autocompletion. I have a custom panel for suggestion options list (for using editor on mobile). By clicking these options user can apply corresponding suggestion to the code.
Problem:
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.
It seems like internal javascript (@codemirror/lang-javascript) options are sorted to the top of the list, and my options come afterwards.
I’m assuming those options get to the top because filter is set to false.
Interestingly, that if I’m typing the whole document token I get proper list of my custom options, like .querySelector(), in the top (without default options with filter set to false (presumably) from @codemirror/lang-javascript internals).
Question:
Is there a way to prevent / control if options from @codemirror/lang-javascript with filter: false are returned from currentCompletions after calling startCompletion?
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.
boost: 99
put startCompletion in macro tasks (setTimeout 1s), also didn’t help.
I don’t know, I’m assuming.
Otherwise I expect my options to be in the top after I call startCompletion, since boost is set to 99 and compareCompletions additionally set
In this example you can see following sequence of actions:
set “doc” content
startCompletions
setSelectedCompletion(0) (“document.”)
acceptCompletion
startCompletions again
as you can see, in suggestions list I have some default tokens listed (presumably coming from javascript-lang package and being unfiltered):
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.
