Discussion:
wrong sorting order of numerical filenames
Serge
2013-12-16 16:15:01 UTC
Permalink
Hello.
I think sorting order of numerical filenames in e2 is wrong.
Please see attached screenshot.
--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.53-1 x86_64
GNU/Linux
Arve Barsnes
2013-12-16 16:20:36 UTC
Permalink
Post by Serge
Hello.
I think sorting order of numerical filenames in e2 is wrong.
Please see attached screenshot.
Well, it treats a string of numbers as one big number instead of several
numbers. I've seen this many places, and believe it to be a feature of many
similar programs.
t***@onepost.net
2013-12-17 03:53:10 UTC
Permalink
On Mon, 16 Dec 2013 20:15:01 +0400
Post by Serge
I think sorting order of numerical filenames in e2 is wrong.
Please see attached screenshot.
Name-comparison essentially revolves around library function g_utf8_collate_key_for_filename(). The latter causes some quirks such as you've described.

Regards
Tom
Serge
2013-12-17 22:52:37 UTC
Permalink
On Tue, 17 Dec 2013 14:53:10 +1100
Post by t***@onepost.net
On Mon, 16 Dec 2013 20:15:01 +0400
Post by Serge
I think sorting order of numerical filenames in e2 is wrong.
Please see attached screenshot.
Name-comparison essentially revolves around library function
g_utf8_collate_key_for_filename(). The latter causes some quirks such
as you've described.
Regards
Tom
As far as i remember (same "bug" in mc long ago), g_utf8_collate_key()
must be used instead of g_utf8_collate_key_for_filename() for normal
alphabetical sorting.
Sorting in all other programs i have is "normal")
--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.53-1 x86_64
GNU/Linux
t***@onepost.net
2013-12-18 00:18:01 UTC
Permalink
On Wed, 18 Dec 2013 02:52:37 +0400
Post by Serge
On Tue, 17 Dec 2013 14:53:10 +1100
Post by t***@onepost.net
On Mon, 16 Dec 2013 20:15:01 +0400
Post by Serge
I think sorting order of numerical filenames in e2 is wrong.
Please see attached screenshot.
Name-comparison essentially revolves around library function
g_utf8_collate_key_for_filename(). The latter causes some quirks such
as you've described.
As far as i remember (same "bug" in mc long ago), g_utf8_collate_key()
must be used instead of g_utf8_collate_key_for_filename() for normal
alphabetical sorting.
Sorting in all other programs i have is "normal")
Use of g_utf8_collate_key() may deal with the problem you're reporting, but causes other(s), especially no distinction between filename 'base' and extension.

In past times I considered trying to get glib maintainers to fix their algorithm (IIRC it partitions the filename into alphanum-separated parts, then works on the parts independently) but I came to the view that the dev's don't take much notice of such things.

Regards
Tom

Loading...