Dominik Riebeling wrote:
> I started wondering how the value "as whole numbers" for the setting
> "interpret numbers while sorting" is intended to work. Currently it
> seems to get changed in svn quite often. However, I haven't seen a
> consensus how this feature is supposed to work (read: sort) gathered,
> especially before committing. A recent discussion is here:
> Maybe I've missed such a consensus -- in this case someone please
> point me to the right direction and ignore this mail :) Changing the
> behaviour of this setting frequently is a rather bad thing IMO. We
> need to specify how we want it to work and implement it that way.
> Doing this kind of "discussion in svn" is a bad thing and can only
> lead to confusion among users. We didn't do this for the "study mode"
> feature either, even if there was a consensus to change it.
> Now, how should this feature sort? From my point of view, I'd expect it to
> - treat digits as numbers. A value of "00" equals to zero and thus
> gets sorted before the number 1, regardless if that is "1", "01" or
> "001". Completely skipping the zero (as it's only leading zeros) is as
> broken as to not strip leading zeros -- "003" should equal to 3 and
> "01" to 1, thus the latter sorting before the former. 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).
> 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 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'm pretty sure I've missed some of my points right now :) What do
> people think about this sorting thing?
> - Dominik
I think it should just be the simplest and easiest to understand.
Any consecutive run of numbers [0-9] are treated as a its value for
This means any non-digit is treated like a separator. Which would
include punctuation, spaces, etc. This also avoid trying to figure out
what the person meant by using a period. Was it a separator, equivalent
to US comma, region setting, real number, etc? That's just a road nobody
is going to agree on.
Same thing if a person is using punctuation, leading zeros, etc to
control the sort order. There's no way to read the persons mind on what
they intended. In all likelihood they're going to use the ASCII sort
The various implementation that have been used by RB have tried to eat
Are all equal to a1. I say throw that out too.
1. Numbers sort before Non-numbers.
- Leading zeros are striped. A leading zero on a zero is still zero.
- 000 becomes 0.
- Some of the code that has been used has trouble with this.
2. Lesser number before greater.
- 1,2,3,4 etc
3. Anything else strcmp.
Received on 2009-03-19