Open ghost opened 8 years ago
Can confirm that the symbol-matcher discards all matches that don't include same first letter.
Right there: https://github.com/atom/autocomplete-plus/blob/master/lib/symbol-store.js#L75
Is there a reason for this limitation? If there aren't any technical constraints, I'd like to see this at least selectable as an option in settings.
Hello
My package specifies PHP class name suggestions and I'm encountering a really strange issue where autocomplete-plus is matching when my prefix has a leading slash and isn't when it doesn't. A concrete example, I'm passing the following suggestions back to autocomplete-plus:
\Psr\Log\LoggerAwareTrait
\Psr\Log\LoggerAwareInterface
I then type
LoggerAware
in a text editor, which becomes my prefix. No results show up, even though it should clearly be fuzzy matching the suggestions. I changeLoggerAware
into\LoggerAware
, now I suddenly get both suggestions.I've been running into similar oddities for some time now, so I took a gander at the source code to figure out what is happening and stumbled upon this [1]: suggestions are always ignored if their first character doesn't match the prefix. This perfectly explains the above behavior: the slash matches the suggestions, but the
L
fromLoggerAware
doesn't.To make things even stranger, if I remove the leading slash from my suggestions:
Psr\Log\LoggerAwareTrait
Psr\Log\LoggerAwareInterface
... and now enter
LoggerAware
, I still get no matches. With the above information, I change this intoPoggerAware
and voilà: two matches because the first character matches!What I'm now wondering is: why are suggestions filtered out if their first character does not match? A fuzzy match can still very much be relevant when it doesn't. Am I wrong in thinking that this check is incorrect or optionally replaced by increasing the score of the suggestion rather than dropping it entirely?
Thanks in advance
[1] https://github.com/atom/autocomplete-plus/blob/master/lib/autocomplete-manager.coffee#L254