Let history-incremental-search-* list rows in chronological order

[lefth]

• zsh-autocomplete version: f3aa3b0
• Zsh version: /usr/bin/zsh ubuntu/5.8-3ubuntu1
• Framework: None
• Plugin manager: None
• Operating system: WSL2 Ubuntu 20.04

1. Paste the following into your terminal and press Enter:
   ...
2. Once you're able to reproduce your problem in the shell session created
   above, copy-paste the contents of your terminal here:

History incremental search shows commands in the documented order ("Live history search, from newest to oldest") until typing starts (correct behavior):

% echo a
a
% echo aardvark
aardvark
% # here pressed Ctrl R
2 echo aardvark
1 echo a

Here, after I type "echo", the order changes and does not show me the most recent command first.

% echo a
a
% echo aardvark
aardvark
% echo
1 echo a
2 echo aardvark

I noticed the shortest commands are shown first. I guess that's because they are deemed better matches. That heuristic makes sense for matching a complete search, but not a partial search! Partial searches are expected to be much shorter than the text they match.

I suggest history results be shown in order as the documentation states. Perhaps the ranking algorithm should be turned on by configuration, and ranking improvements could be filed as a separate issue?

Or could this be solved by ranking all perfect substring matches equally? In that case heuristics like edit distance would only be used when the incremental search is not an exact (substring) match.

[marlonrichert]

First off, it's not a bug; it's a feature. Although, indeed, the documentation could be better.

If you want to have the results sorted in chronological order, just press ↑.

[marlonrichert]

That heuristic makes sense for matching a complete search, but not a partial search! Partial searches are expected to be much shorter than the text they match.

I have no idea what you mean with "partial" vs "complete" searches. Care to explain?

Or could this be solved by ranking all perfect substring matches equally?

I'm not sure what you mean with that either. 🙂

[lefth]

Oh, interesting point about "up arrow" at the search prompt. I'll have to get used to that--there's history search in order, but not live anymore. I think this will work about as well, though I'm used to seeing the most recent match right away, as I type.

When I wrote "partial" search, I meant a search whose terms, from the user's perspective, have not been fully input. When doing an incremental search, the system should assume the search is not complete. If I typed "a" into a search prompt then confirmed, short results starting with "a" would be a reasonable answer. But if I've just started to type, the system should not assume "a" is likely so be the full search string. It would be a better user interface for the system to always assume the search terms are incomplete and give results accordingly.

Or could this be solved by ranking all perfect substring matches equally?

Looking at the code, it seems I assumed more logic than it actually uses. I assumed results were ordered by a point ranking system (fuzzy ordering based on how good of a match it is), but are they just ordered by length? My suggestion isn't relevant in that case. That aside, I find the longer commands in history harder to remember than the shorter ones. The shorter command history items are things I would not want command history for, like "cd ffmpeg-git" and "killall ffmpeg". What's the use case for putting short commands at the top?

[marlonrichert]

That aside, I find the longer commands in history harder to remember than the shorter ones. The shorter command history items are things I would not want command history for, like "cd ffmpeg-git" and "killall ffmpeg".

I see your point there. It's something I've gone back and forth on in the past. I suppose I could make it configurable.

What's the use case for putting short commands at the top?

• The shortest match is the least number of changes away from the original. It is the most "exact" match.
• It makes ^R provide a different way of searching than ↑. It felt redundant to have them both do the exact same thing.
• It allows you to progressively complete longer commands: You start typing, find a short command that's a subset of the longer command you're looking for, then press tab to insert the shorter command, and now you've filtered out a whole bunch of false positives. Rinse, lather & repeat.

[lefth]

The shortest match is the least number of changes away from the original. It is the most "exact" match.

Another way of describing "partial search" is: when I do an incremental search, I consider it as having an implicit "*" wildcard at the end. As such, a shorter string is not a more exact match. But arguably a command where the term occurs earlier is a more exact match, and a command where the term matches with a left word boundary is a better match. For example, "n" matches "null" better than "end". But IMO that's a separate issue, and ranking algorithms are easy to extend after the initial refactor (to sort based on more than one factor) is done.

What do you think about swapping the orderings of Ctrl R and ↑? I suggest this because live search is conceptually like searching for "foo*", and the search is narrowed down by continuing to type, while the ordered history search is performed once all the complete terms have been entered. This second search type can do more sophisticated ranking because the system has more information. Whereas when I type Ctrl R and search for "f", the system knows almost nothing about what I want so any clever ordering it tries to do will be unhelpful.

It allows you to progressively complete longer commands

This makes a lot of sense with cd, but other long commands don't tend to be composed of short commands. At least I don't see how this would work for me, but I will think about it as I type commands and use the completion system.

[marlonrichert]

I am currently testing ^R with chronological results and it works quite well. I will probably push in the changes later today.

[lefth]

Thanks! Do you intend to give the ↑ menu a more sophisticated sort? If so I could write a sort function that would take match closeness into account. I once made that sort of ranking for text search in a different situation.

[marlonrichert]

Thanks, but no thanks. I’ve gotten feedback before that users expect ⬆️ to produce results in (anti-)chronological order. 🙂

[marlonrichert]

It's there now, plus some other minor improvements to the incremental history search. Enjoy!

---

PS: If you indeed enjoy using my software, please consider sponsoring me. 🙂