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.
