-
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fuzzy completions #308
fuzzy completions #308
Conversation
- configurable to switch back to the previous strict match (REPL-based) completions
faaaab2
to
9d2487a
Compare
9d2487a
to
e2021ba
Compare
Codecov Report
@@ Coverage Diff @@
## master #308 +/- ##
==========================================
- Coverage 54.92% 54.88% -0.05%
==========================================
Files 42 42
Lines 2933 2602 -331
==========================================
- Hits 1611 1428 -183
+ Misses 1322 1174 -148
Continue to review full report at Codecov.
|
- reflect fuzzy completion adapter addition - revert back to one-liner statement for minor visibility improvement
Alright, I updated precompile statements. It would be nice if I could have a feedback on this :) |
) | ||
end | ||
|
||
function fuzzycompletionadapter( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fairly similar to the replcompletionadapter
-- maybe we could have an is_fuzzy
kwarg and do something like
repl_provider = is_fuzzy ? FuzzyCompletions : REPLCompletions
repl_provider.completions(...)
plus have an if
block for the different filter methods below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, then the code after repl_provider
used would be really type-instable (I confirmed that Julia 1.4 can't infer the type of repl_provider.completions
, for example)
I haven't taken any actual benchmark, but I would like to endure the verbose code for performance here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm fair enough then. I don't think the dynamic dispatch would make much of a difference, but let's just keep this as-is then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the dynamic dispatch would make much of a difference
yeah maybe. I may be too nervous about dynamic dispatches..
I will refactor them in the future when I get confidence that dynamic dispatches here don't matter.
should work once JuliaRegistries/General#11930 gets merged.
After that I will refactor the test cases a bit and update precompile stmts.