Re: Bad sort order under glibc 2.2

[Pavel Roskin <proski gnu org>]

Hi, Dmitry!

>     But changing case-sensitivity of file sort order is not good too -- there
> is a long ago established practice of naming "important" files with a leading
> capital, for those to be desplayed first (README, Makefile vs. makefile,
> etc.), and this practice is documented.  Oh, mamma mia, do we need a
> strnocasecoll()? ;-)  Somebody of POSIX-writers should have thought about
> this issue before...

That's exactly the point. If you do locale-specific sort you don't have a
choice between case-sensitive and case-insensitive.

On the other hand, MC (both editions) gives user the choice between
case-sensitive and case-insensitive file sort. Some people want to use
locale sort in MC, some don't.

MC currently uses strcoll() for case sensitive sort (with fallback to
strcmp() if strcoll() is not available) and g_strcasecmp() for case
insensitive sort.

This is obviously wrong. It's one of the most critical bugs that is
delaying the next release of GNU Midnight Commander.

I have some ideas what to do, but neither of them is really good.

1) Have a choice between three types of sort. Unfortunately, the code
inmlementing the "Sort order" dialog is very hard to modify. Besides, we
risk to confuse users. They'll have to choose between "case-sensitive",
"case-insensitive" and "locale default".

2) Put "use locale for file sort" somewhere in the configuration. This
means that you cannot have different sort type on panels.

3) Determine whether strcoll() is case insensitive at runtime and only use
it for case insensitive (or only case sensitive, or for what is really
does) sort. Ugly as hell.

4) Remove strcoll() alltogether. It was introduced in a patch, the patch
doesn't work well, so let's revert it and wait util somebody makes a good
patch. This is not really a solution. I believe that many GNOME users
expect the locale to be respected.

Better ideas would be appreciated. I'm crossposting to mc-devel because
the issue is very important and should be discussed by developers.

-- 
Regards,
Pavel Roskin