Use array reversal instead of array sorting.
There's no need to do a full numerical sort here, since we know the keys will be in reverse numerical order, because (R) searches in last- to-first order. Not a big deal, but this is just simpler and presumably more efficient. Also cleaned up a rather confusing comment about (on) being used to remove duplicates, which it definitely doesn't.
This commit is contained in:
parent
3c7b079275
commit
fd31074470
1 changed files with 3 additions and 5 deletions
|
|
@ -200,12 +200,10 @@ function _history-substring-search-begin() {
|
|||
#
|
||||
# Find all occurrences of the search query in the history file.
|
||||
#
|
||||
# (k) turns it an array of line numbers.
|
||||
# (k) returns the "keys" (history index numbers) instead of the values
|
||||
# (Oa) reverses the order, because (R) returns results reversed.
|
||||
#
|
||||
# (on) seems to remove duplicates, which are default
|
||||
# options. They can be turned off by (ON).
|
||||
#
|
||||
_history_substring_search_matches=(${(kon)history[(R)(#$HISTORY_SUBSTRING_SEARCH_GLOBBING_FLAGS)*${_history_substring_search_query_escaped}*]})
|
||||
_history_substring_search_matches=(${(kOa)history[(R)(#$HISTORY_SUBSTRING_SEARCH_GLOBBING_FLAGS)*${_history_substring_search_query_escaped}*]})
|
||||
|
||||
#
|
||||
# Define the range of values that $_history_substring_search_match_index
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue