Natural sorting please...

[jsmorley]

It's important that you understand what is meant by lexicography sorting alphabetically.

As I mentioned,

m2Name
m22Name
m222Name

Would NOT sort in that order. It would sort as:

m222Name
m22Name
m2Name

Since "2" would sort before "N". The entire string is considered in the sorting, not just the numbers.

I can't help any more than this. The way Rainmeter / FileView sorts is entirely correct using lexicography sorting.

[Yincognito]

It isn't the norm because that's how string are compared in all programs: from left to right, and from the lowest char code to the highest. Whatever programs that seem to do otherwise, e.g. Windows Explorer, they don't: they actually space pad numbers internally. So, the only question here really is... who should do the padding needed for the desired order, the users or the devs.

[sl23]

I can see that now, but you confused me the way you first posted.
Alphabetical sorting is machine sorting and perform on a column basis, not numerical linear basis. ie, it doesn't take into account what the following digit is.

Natural sorting does. Hence why I posted asking for that. Your original reply caused the confusion!

Ok, so now we're both clear...
Is there a way to have Natural sorting without zero padding? It's really annoying and awkward trying to find stuff as my pics show.

[sl23]

It isn't the norm because that's how string are compared in all programs: from left to right, and from the lowest char code to the highest. Whatever programs that seem to do otherwise, e.g. Windows Explorer, they don't: they actually space pad numbers internally. So, the only question here really is... who should do the padding needed for the desired order, the users or the devs.

Well, that was what I was requesting, that it be done internally, and it turned into a big debate!
Seriously though, Can we please have the option in the Rainmeter settings for this? Low priority or not, it would be nice for it to be a consideration and eventually added.

[jsmorley]

Implementing true "nature sorting" is not trivial. There are some libraries out there that deal with the complexities of stuff like "case", "non-ascii characters", and all that, but I'm not sure how easy it would be to shoehorn that into Rainmeter and FileView, and if there would be "backwards compatibility" issues to consider.

Again, I just don't see this as a high priority. Zero-padding numbers in strings is cumbersome, but works.

[SilverAzide]

You kids today...
This is why the only proper character set is the ASCII character set, and the only proper sort order is ASCII order.

/jk

[jsmorley]

You kids today...
This is why the only proper character set is the ASCII character set, and the only proper sort order is ASCII order.

/jk

Yeah, but even ASCII has some issues with Natural Sorting:

a
B
A
b

Would sort as:

A
B
a
b

Since "case" is considered in sorting algorithms.

Notepad++ has gone to great lengths to deal with this:

1.jpg

[SilverAzide]

Would sort as:

A
B
a
b

Since "case" is considered in sorting algorithms.

That's not really a "problem", per se, that's the "correct way".
This is why we need to go back to uppercase 8.3 filenames.

/jk (again)

[Yincognito]

By the way, I personally ALWAYS name my numbered files by zero padding, since Total Commander (the file manager I use) uses the same lexicographic order. The nice thing is that it has multiple / mass renaming, so if not zero padded already, it can be done in like one or two second or such, for as many files as needed.

So, you see, it's not only a Rainmeter thing. If it was trivial, all programs would do it. When the number is at the start or end of the string it very slightly becomes easier, but one would still need a proper solid algorithm to do it.

A job for the incompetent, and NOT even "artificially" intelligent ChatGPT...

[jsmorley]

That's not really a "problem", per se, that's the "correct way".
This is why we need to go back to uppercase 8.3 filenames.

/jk (again)

RAINME~1