Skip to content
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

ranked match: prefer input order over alphabetical order for user-specified completions #5035

Merged
merged 2 commits into from
Dec 12, 2023

Conversation

krobelus
Copy link
Contributor

@krobelus krobelus commented Nov 18, 2023

When using either of

set-option g completers option=my_option
prompt -shell-script-candidates ...

While the search text is empty, the completions will be sorted
alphabetically.
This is bad because it means the most important entries are not listed
first, making them harder to select or even spot.

Let's compare input order before sorting alphabetically.

In theory there is a more elegant solution: sort candidates (except if they're user input) before passing them to RankedMatch, and only use stable sort. However that doesn't work because we use a heap which doesn't support stable sort.

Closes #1709, #4813

@krobelus krobelus force-pushed the prefer-input-order-over-alphabet branch 2 times, most recently from 838d7cd to 5806523 Compare November 20, 2023 08:11
@krobelus krobelus marked this pull request as ready for review November 20, 2023 19:53
String completion;
String on_select;
DisplayLine menu_entry;

bool operator==(const Candidate& other) const { return completion == other.completion; }
auto operator<=>(const Candidate& other) const { return completion <=> other.completion; }
auto operator<=>(const Candidate& other) const { return std::tie(completion, input_order) <=> std::tie(other.completion, other.input_order); }
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit weird, equality and ordering are not consistent with each other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true. Happily we don't need this change at all because the comparison is only used for deduplicating full-line completions. For those I don't think we care about preserving the input order.
And if we do care, we could use a stable sort for <c-x>l completions.

Same for buffer completions, I don't have a strong opinion on whether they should respect input order.
I'm leaning towards no but if we do want it it'd be

diff --git a/src/commands.cc b/src/commands.cc
index fb0b790dd..097895c98 100644
--- a/src/commands.cc
+++ b/src/commands.cc
@@ -185,8 +185,8 @@ static Completions complete_buffer_name(const Context& context, CompletionFlags
         if (RankedMatch match{bufname, query})
             matches.emplace_back(match, buffer.get());
     }
-    std::sort(filename_matches.begin(), filename_matches.end());
-    std::sort(matches.begin(), matches.end());
+    std::stable_sort(filename_matches.begin(), filename_matches.end());
+    std::stable_sort(matches.begin(), matches.end());
 
     CandidateList res;
     for (auto& match : filename_matches)

While at it, remove a needless reserve() call and reserve an extra slot
because "InsertCompleter::try_complete" might add one more element.
…cified completions

When using either of

	set-option g completers option=my_option
	prompt -shell-script-candidates ...

While the search text is empty, the completions will be sorted
alphabetically.
This is bad because it means the most important entries are not listed
first, making them harder to select or even spot.

Let's apply input order before resorting to sorting alphabetically.

In theory there is a more elegant solution: sort candidates (except
if they're user input) before passing them to RankedMatch, and then
always use stable sort. However that doesn't work because we use a
heap which doesn't support stable sort.

Closes mawww#1709, mawww#4813
@krobelus
Copy link
Contributor Author

krobelus commented Dec 2, 2023

updated the builtin uses of shell-script-candidates.

@@ -25,7 +25,7 @@ define-command -params ..1 \
cut -f 1 "$tags" | grep -v '^!' | uniq > "$namecache"
fi
cat "$namecache"
done} \
done | sort } \
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Piping into sort means we wont get partial results in shell-script-candidates, which is a shame in the cases such as doc or man where we could get candidates progressively out of the find command. I wonder if sorting really is better than random order.

@mawww mawww merged commit 533f51c into mawww:master Dec 12, 2023
6 checks passed
krobelus added a commit to krobelus/kakoune that referenced this pull request Jan 13, 2024
As of recently, shell script candidate completions are computed in
the background, and displayed incrementally.
Sorting completions means we can't show partial results.

We do this for "ctags-search"; but if there is only one ctags file
there is already a sensible order (which is slightly different than
what GNU sort does). So let's preserve the order in that case.
The number of completions is probably too high for an order to be useful.

Similarly, for "man", sorting is probably not very helpful because
there are so many results.

See mawww#5035 (comment)
evannjohnson pushed a commit to evannjohnson/kakoune-ev that referenced this pull request Jan 25, 2024
As of recently, shell script candidate completions are computed in
the background, and displayed incrementally.
Sorting completions means we can't show partial results.

We do this for "ctags-search"; but if there is only one ctags file
there is already a sensible order (which is slightly different than
what GNU sort does). So let's preserve the order in that case.
The number of completions is probably too high for an order to be useful.

Similarly, for "man", sorting is probably not very helpful because
there are so many results.

See mawww#5035 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove sorting of user-supplied insert completions
2 participants