BUG: Reverting to empty query does not reset sort order

[kimono-koans]

I am seeing some other weird behavior. Yikes. After I delete my query, or the query returns to empty, the items are not sorted in their original order?

Originally posted by @kimono-koans in #988

[kimono-koans]

My tiebreak criteria are:

pub const TIEBREAK: &[RankCriteria] = &[
    RankCriteria::Score,
    RankCriteria::Index,
    RankCriteria::NegLength,
];

When reverting to an empty query, with an empty score, the sort order should be index first.

However, when I revert to an empty query on latest and master, matcher appears to run, but sorts in alphabetical order (!). See:

[LoricAndre]

What do you set as index for your items ?

[LoricAndre]

Unfortunately, for performance reasons, the sorting might be unstable if you don't override SkimItem::get_index() and set indexes before sending in the items. This is not as fluid as I'd like it to be, but stable merging of sorted sublists in a parallel matcher that does partial runs is a very complicated problem, especially when constrained by performance as tightly as I'd like skim to be

[kimono-koans]

Unfortunately, for performance reasons, the sorting might be unstable if you don't override SkimItem::get_index() and set indexes before sending in the items. This is not as fluid as I'd like it to be, but stable merging of sorted sublists in a parallel matcher that does partial runs is a very complicated problem, especially when constrained by performance as tightly as I'd like skim to be

IMHO this may not be a good idea for maybe a few reasons:

• First, it makes it more difficult to feed (harder to keep a consistent index) from multiple threads (which BTW crossbeam is designed to do as a MPSC queue). You say use an AtomicUsize. I've tried and still struggled to keep a consistent index.
• Second, first come, first serve makes intuitive sense, unless explicitly overridden. Which is probably why it was the prior behavior.
• Third, it needlessly makes SkimItems 8 bytes larger.

I'm willing to bet enumerate is just as fast?