mailing list of musl libc
 help / color / mirror / code / Atom feed
From: ellie <el@horse64.org>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] A journey of weird file sorting and desktop systems
Date: Fri, 28 Jan 2022 15:57:44 +0100	[thread overview]
Message-ID: <f91a163d-7476-1f64-cdbc-6678d3b68d4c@horse64.org> (raw)
In-Reply-To: <20220128141049.GI7074@brightrain.aerifal.cx>

I don't think nowadays the majority of users should be expected to be 
traditional *nix users with terminal knowledge anymore. And most modern 
desktop distros don't default to such a sorting as far as I can tell, 
and instead to en_US or alike - but all those which use musl are left 
stranded with "C" sorting. The type of users who are hit most by this 
are not going to be the type who know what a terminal is, what musl is, 
or how to voice their opinion on LC_COLLATE because their file manager 
looks so weird. So if you want them to show up here that probably won't 
happen. Beyond myself, I suppose.

I think for a typical user-friendly desktop the need is kinda clear, so 
I'm not sure what other sort of setting would need to be introduced 
still. If musl is meant to be used on desktop distros, this just seems 
kind of mandatory, or I'm not really getting why it wouldn't be.

My apologies however if I'm misunderstanding, but that was basically 
your question/what you're saying is delaying it, right? Sorry if you 
didn't want further input from me on this, I hope I read your e-mail right

On 1/28/22 3:10 PM, Rich Felker wrote:
> On Fri, Jan 28, 2022 at 02:41:38PM +0100, ellie wrote:
>> After spending a bit wondering why files like "elder1" and "Elder2"
>> end up at completely different spots in the file list on my
>> postmarketOS (=Alpine-based) system, I filed a ticket with the Nemo
>> file manager. Turns out Nemo just uses locale-dependent sorting, so
>> I spent an hour trying to set LC_COLLATE to fix this, until I
>> stumbled across the remark on musl's website that LC_COLLATE sorting
>> is simply not supported. So I seem to be stuck with this, which I
>> did not expect.
>>
>> This to me seems kind of disastrous on a desktop system. I just fail
>> to see any average default user (who doesn't know ASCII in their
>> head) expecting "elder1" and "Elder2" to be miles apart in a sorted
>> listing even as a default US person, let alone in some other
>> language that may be expected to use a different sorting for
>> whatever reason. (This affects umlauts too, I assume? So that'd be
>> most European languages having file lists entirely messed up, too.)
>> The sorting shouldn't be stuck as something that just makes sense to
>> programmers and balks at any special vowels, and it appears at least
>> as of now there is just no way to fix this.
>>
>> Should desktop file managers like Nemo not be using this sorting
>> function? Or is musl not intended for desktop use, and postmarketOS
>> should switch? Otherwise, it seems like this omission in musl seems
>> like kind of a big deal. Or is it really just me who is constantly
>> confused as to where any file is at in any file lists...?
>>
>> Or in other words, would be kind of cool if this could be changed
> 
> LC_COLLATE functionality is just not designed or implemented yet, due
> to lack of interest/participation from folks who want it to happen. I
> very much do want it to happen, but I don't want to design something
> (data model for efficient collation tables & code to use them) only to
> have it turn out not to meet everyone's/anyone's needs because there
> was nobody to bounce questions/testing/what-if's off during the
> design.
> 
> A big part of this is probably that, historically, *nix users tend to
> be happy with (or even prefer, which they can explicitly set via
> exporting LC_COLLATE=C) codepoint-order sorting of directory entries,
> like Makefile and README appearing at the top. So to get these folks
> to care you have to have another setting where collation order
> matters.
> 
> I'm happy to restart the process for getting this done if ppl are
> interested.
> 
> Rich

  reply	other threads:[~2022-01-28 15:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28 13:41 ellie
2022-01-28 14:10 ` Rich Felker
2022-01-28 14:57   ` ellie [this message]
2022-01-28 16:58     ` enh
2022-01-28 18:01       ` Rich Felker
2022-01-28 18:33         ` enh
2022-01-28 19:22           ` Rich Felker
2022-01-28 19:47         ` Markus Wichmann
2022-01-28 18:01     ` Ariadne Conill
2022-01-28 17:54   ` Ariadne Conill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f91a163d-7476-1f64-cdbc-6678d3b68d4c@horse64.org \
    --to=el@horse64.org \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).