feat: sort source entries before slicing when using max_item_count #1765
+25
−12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
meeehdi-dev
changed the title
hrsh7th
reviewed
Dec 10, 2023
lua/cmp/view.lua
Outdated
| -- source order priority bonus. | ||
| local priority = s:get_source_config().priority or ((#source_group - (i - 1)) * config.get().sorting.priority_weight) | ||
|
|
||
| for _, e in ipairs(s:get_entries(ctx)) do | ||
| e.score = e.score + priority | ||
| table.insert(entries, e) | ||
| e.source_name = s.name -- store source name for filtering after sort. |
There was a problem hiding this comment.
You don't need assign e.source_name.
You already can use e.source.name instead.
There was a problem hiding this comment.
I didn't notice the source was available in the entry. Thank you!
|
LGTM. |
|
Cool feature - thank you! Should the documentation be updated to remove |
williamboman
pushed a commit
to williamboman/nvim-cmp
that referenced
this pull request
Feb 26, 2024
…rsh7th#1765) * feat: sort source entries beforce slicing when using max_item_count * feat: optimize filtering by max_item_count after sort * fix: useless check if max_item_counts map is initialized * fix: directly use entry source object when checking max_item_count
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
When using the prop
max_item_count, there is a known catch (sorting issue) from the doc:This PR makes it so the source entries are sorted before being sliced and fed to the full list of entries and then sorted again.
If the performance hit is too big, we could maybe add an optional boolean option such as
sort_before = truealong withmax_item_count, to make sure the user still wants this sorting to happen even if it is slower.EDIT:
Just had another thought... We could maybe avoid all this sorting X times per source + 1 time per group index, while still keeping the results accuracy, but it would bring some changes to how the final list is created. I'll try that later and maybe create another PR if it's worth it.
EDIT2:
Sorry for editing this PR once again but the first version felt wrong.
So this time what i did is just moving the whole
max_item_counthandling.We fetch all the entries, we sort them, and at the end, depending on the source of the entry, we filter them out if they reached
max_item_count.I don't have that much experience with array manipulation in lua but i feel like the second commit would be way better performance-wise than the first one.
Thanks for your time.