From: Thomas Martitz <thomas.martitz_at_fhtw-berlin.de>
Date: Wed, 18 Mar 2009 23:18:02 +0100

Am 18.03.2009 22:22, schrieb Paul Louden:
> Dominik Riebeling wrote:
>> A situation
>> where a folder can contain files starting with "02" and "4" the same
>> time is something that could happen and still not being intentional
>> (just think of copying files from various albums to a mix folder).
> I agree that it could be unintentional, but disagree that "numeric
> sorting" matters in this case - if you have a mix of random songs, why
> does 03 need to be between 2 and 4? Meanwhile, if someone
> intentionally prefixes something with a 0, they intend for it to be
> first, so it should be. This sounds like a case of "let's make the
> unimportant case work one way, while choosing to break the case where
> people make intentional changes."

I agree with Llorean, this case is purely personal preferences I think.
03 and 2 in the same folder, could be accidental (from mixed albums), or
intentional. We sort it, but I'm not sure if there's really *one*
correct way for this case.

People can rely on ommitting leading zeros now since we can sort it
correctly numerically. That makes me think that any leading zero may
very well be intended.
>> Either treat digits as number or don't treat them as numbers at all.
>> - Spaces shouldn't get collapsed. A space is a space, and "interpret
>> numbers" doesn't tell anything about spaces. At least at some point
>> during the lifetime of this setting spaces were collapsed. Nothing
>> that is a number ...
I don't see what's wrong with ignoring spaces. It's obvious that spaces
aren't real part of the names when it comes to sorting (as in 1 and 2
spaces should be sorted differently).
Why would anyone want to sort by spaces anyway? This doesn't make any
sense to me.
But yes, the option doesn't tell about that. Should we change the
description, or how it's working?
>> This still leaves some open issues I'm not sure how to deal about:
>> - how are floating-point numbers to be treated? "1.001" is smaller as
>> "1.01" when treating as numbers, so on the one hand I'd expect them to
>> sort that way. On the other hand, recognizing the dot as decimal
>> separator is broken as well -- not all languages use it as decimal
>> separator (like german using the comma). Stopping the number-treating
>> at dots is also kinda broken -- how should a naming be handled as
>> "discnumber.tracknumber", i.e. like "1.2", "1.10" -- which one has to
>> be sorted first? The best solution here might be to treat all numbers
>> as single numbers, regardless if they might be floating point numbers
>> -- I guess it's more common to have a "1.3" numbering to mark
>> discnumber.track instead of a floating point number "1.003".
>>
> I expect people will number disks 1.01 - 1.12 rather than 1.1, 1.2,
> 1.10, 1.12. This is only my personal assumption, but if that's the
> case, our current method works for it.

Decimal numbers and discnumber.tracknumber works with the current svn.
1.1 is sorted after 1.01, as well as 1.10 is sorted after 1.1 (or 1.2).
And it doesn't take the dot specially as seperator, but any non-digit,
so it will work for commata too.

>> I'm pretty sure I've missed some of my points right now :) What do
>> people think about this sorting thing?
>>
> Well, we're currently using an "existing" algorithm. One that *may* be
> used in other FLOSS (I don't know, and haven't investigated). To me,
> the two sides of the argument are basically "do we want to use it
> as-is, such that our sorted lists look the same as lists in other
> applications, or do we want to define our own rules for 'natural' list
> sorting?" Of course, this is dependent upon research I haven't done
> (specifically, do any other applications use this sort algorithm).
>
> Maybe we should just see if various FLOSS file browsers have a common
> "natural" sort, and use it, so that our files are likely to show up in
> the host's browser the same order as they show up in ours?

If you search for logs, we had a discussion yesterday starting here:
http://www.rockbox.org/irc/log-20090317#17:53:35 and today starting
here: http://www.rockbox.org/irc/log-20090318#19:25:26
Both are Flyspray-bugreport induced, and I can't remember another
discussion other than those before the initial commit.

I think the only remaining problem is FS#10031, which would be an
relatively easy fix (it sorts filenames starting with chars between 'Z'
and 'a' differently than normal strcmp, regardless of numbers in the
name, because it uses toupper instead of tolower for case-insensitive
sorting), but it would require to leave the path of using the original
algorithm without changing again.
Received on 2009-03-18