Add 'alphanumeric sort' commands

[seb-bl]

Implements #4153 with the crate mentioned in the discussion of the issue.

This adds 2 new commands, sortn and rsortn, corresponding to the existing ones (sort and rsort), and they sort according to https://docs.rs/alphanumeric-sort/1.4.4/alphanumeric_sort/fn.compare_str.html

[the-mikedavis]

It's a short (~100L) block of code within the library and the library includes a bunch of other functions I don't think will be used in the future so I think we should vendor this block https://github.com/magiclen/alphanumeric-sort/blob/bea0284409f68407dd25b432fd901b62f6e944e7/src/lib.rs#L95-L199

[seb-bl]

I removed the dependency, and added a function to compare the strings.

When I copied the source, I realized the handling of long numbers was incorrect (it accumulates it in a f64, thus rounds it). I looked at the other crate, and it had a similar problem (accumulating the number in a u64).

So I implemented my own function. It orders numbers with leading zeroes like the crate alphanumeric-sort, but uses the slice containing the digits instead of a f64 for the comparison

[kirawi]

Just to note, I think that using a u64 would've been okay. len() returns a usize which is equivalent to u64 on 64bit systems. Assuming that each number is equivalent to a byte, then it could handle 16,384 petabytes of data.

[kirawi]

This should be moved into a

#[cfg(test)]
mod tests {
}

block at the bottom of the file.

[kirawi]

By the way, make sure to run cargo xtask docgen and commit the changes to make CI pass.

[seb-bl]

Thanks for the hints 🙂

I think I have not explained the problem with the u64 correctly. When encountering a number,lexical-sort parses the number into a u64, digit by digit, it multiplies the number by 10 and add the current digit (at this line). So for example "18446744073709551616" (=2^64) would cause an overflow. Numbers this long are not very common, but may still happen

[leandrobbraga]

nit: you could remove both reverse and alphanumeric parameters and pass a single parameter called cmp_fn which is a FnMut(&Tendril, &Tendril) -> Ordering leaving to the caller to say how it want the ordering.

See: #8436

[the-mikedavis]

I agree with @leandrobbraga - this block is a little dense and we can make the call sites for sort_impl a little cleaner by moving these closures to parameters of sort_impl.

So this function would replace the reverse parameter with a compare_fn: impl FnMut(&Tendril, &Tendril) -> std::cmp::Ordering, param and then this block can be just fragments.sort_by(compare_fn);.

We could also use this opportunity to drop the args parameter which is currently unused