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."
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 ...
This is originally based on a natural sorting algorithm, which does a
lot more than numbers it seems. My understanding was the original intent
was to simply fix 1, 10, 2, 3, 4 into 1, 2, 3, 4, 10. I don't see why
this *should* ignore leading zeros. I don't think we should ever assume
any part of a filename is unintentional. I think assuming numbers are
written as a human normally does is fine (1, 2, 3, 10, 11, 12) but if
someone chooses to add something to alter sorting we should still
respect it. You don't accidentally add a 0, and if there are random
zeros in a mix folder the order of playback almost certainly isn't meant
to be 2, 03, 4, but rather "whatever order" if they just chose to
haphazardly mix them.
Also, which comes first: 001 or 01? If we're going to recognize that 001
has one more zero than 01, why don't we recognize that 00number has more
zeros than 0number, even if the two numbers are different?
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.
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?
