> I miss the time when computers did what you told them to, instead of trying to read your mind.
You may be looking at that time through rose-tinted glasses. I don't like when computers lie to me either, but "mind-reading" is really helpful in ways we take for granted, like autosave. Desktops can have an option to sort files truly alphabetically, but the more common case should always be the default; that's the definition of "intuitive".
I don't want to put leading zeroes before every all the single digit numbers in my file names. (And then potentially go come back later and add even more leading zeroes once the maximum number reaches three digits.)
---
I split all of my audiobooks into chapters. I use the format "Chapter 01.mp3" (or "Chapter 001.mp3" when there are > 99 chapters) because some (all?) MP3 players are too stupid to sort numbers properly and I want my audiobooks to work everywhere.
This works, but it looks kind of ugly and creates extra work—yes I have scripts to automate it, it's still an extra step—and it would be great if I could just trust that every device will understand numbers.
> ... it would be great if I could just trust that every device will understand numbers.
Strings are not numbers, even if some part of their content "looks like a number."
> I will add that I'm plenty "smart" enough to understand that "10" comes before "9" in a strictly alphabetical sense, and I still want my file managers to sort "9" before "10".
Problem is, this is your preference for a specific situation. Which may not be another person's preference in the same situation nor yours in a different situation.
So what are programs to do?
Display strings in a consistent, documented, manner. Which is lexicographical ordering in all cases lacking meta-data to indicate otherwise.
Strictly speaking 9, 1 and 0 are not in the alphabet so can't be sorted alphabetically.
And I think most "normal users" wouldn't expect that programmers generalize the alphabet like we do.
Maybe I'm weird but I prefer the way zero padding looks :)
I personally think the misalignment of lines where the numbers have different lengths looks (a lot) uglier than having zero padding. Sometimes it even throws _me_ off because the numbers have different lengths and ... well it just doesn't look sorted to me! :)
So the bonus of zero padding is that it'll be sorted correctly even if the file manager tries to be "smart" and sort incorrectly.
It's great if DEs build this and give it a name. It's even better if they have a different one that deals with SI prefixes too. But it's not good if "alphabetical order" means that.
Amen.
> I split all of my audiobooks into chapters. I use the format "Chapter 01.mp3" (or "Chapter 001.mp3" when there are > 99 chapters) because some (all?) MP3 players are too stupid to sort numbers properly and I want my audiobooks to work everywhere.
Well, some car and kitchen radio manufacturers will probably never get this right. In my car (which tends not to be brand new) they even messed up UTF-8 chars, which gets me laughing every time a track has them. It's become a running gag with my wife, "Oh, listen up, it's &%=?! again".
> (all?)
Well, I kind of hate to say this, but Apple got this right with the iPods. They even regarded the metadata fields `sort-*` (e.g. sort-album), movement-name (for series) and movement-index (for part). With these fields they really group and sort my audio books as I expect it to be.
I even wrote my own software to fill these tags appropriately, so that I don't need to split my audio books. I'm pretty happy using `m4b` files - an mp4 / m4a container with chapter support, which is supported perfectly fine on my iPod Nano 7g and my Android Phone (using Audiobookshelf[1] and Voice[2]). After all these years, the iPod Nano 7g to me is the PERFECT portable audio book player with 2 exceptions: Repairability and the proprietary Apple headphone remote protocol [3].
But we have so many textual representations of numeric values that I'm assuming the "mind-reading" goodness only works for a small subset. And the subset will be somewhat intuitive for developers but unlikely to be so for non-technical people.
For example, does the order handle numbers with fractions (decimal points)? If yes, does it require a at least one leading digit (zero)? Does a.12345 come before or after a.345?
Does it handle thousand separators? What about international thousand and decimal separators (e.g. Euro-style . for thousand separation and , for decimal separation).
Does it handle scientific notation?
If the answer is no to any of these questions, it's likely to lead to surprise/confusion.
It's like a feature request that initially sounds reasonable and useful but once you explore the requirements in detail you realize there are too many edge cases to be able to meet the request in a non-brittle way.
Given that this idea goes back more than two decades, has been the default behaviour of the most used OSes for many years, with no major outcry, I think empirically we can be fairly certain that it does not routinely lead to a lot of surprises and confusion.
The specific option for numeric sorting is “kn”.
As far as I can tell, every operating system and many other interfaces tend to use this standard algorithm.
https://www.unicode.org/reports/tr35/tr35-collation.html#CLD...
Worse, if the answer is yes to any of these questions, it's also likely to lead to surprise/confusion. The only way to win is not to play.
The answer to all of those questions is no for lexicographic ordering. Lexicographic ordering leads to surprise and confusion as a result.
> It's like a feature request that initially sounds reasonable and useful but once you explore the requirements in detail you realize there are too many edge cases to be able to meet the request in a non-brittle way.
It's been on windows and macOS for coming up on 25 years, and is in practically every modern UI. It’s reasonable.
More to the point of the article--if you want things sorted by date, sort by date. I think most laypeople aren't looking at long CHAR1234_5678 filenames anyway, they're looking at thumbnails and dates.
The today standard way of sorting is well defined, unambiguous, and natural. Lexographic has its place, but user facing interfaces ain't it.
Just no
User interfaces that try to be cleaver are a pita.
Keep it simple, and avoid the confusion with corner cases that otherwise will baffle users. Like this
We want to minimize surprises and mysteries, but computers have so much hidden complexity it's impossible to eliminate them. If users were shown a full description of how every feature on their computer worked before using it, they'd quickly start ignoring the descriptions. There should probably be a tooltip or "manual entry" for "by name" for those who are curious, and it should never be labeled "alphabetical" because it's not. But cases like the author's, where he assumes a feature works differently than most people (including the designers) assume, can't be helped.
I guess you mean "after"? Otherwise it seems to me you're agreeing with OP.
> desktops don't label this sorting "alphabetical" (E: and it would really be "lexicographic"*), they label it "by name" (an informal criteria), so technically they're not lying.
FYI the more formal name for the "by name" order is "natural sort order".
Depends on which direction you're sorting in, no?
I have some beef with microsoft, that you can only change this at the Computer level, not per user (see registry key below). Also they call it natural sorting for users, but logical sorting internaly. Unify your termini!
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer] "NoStrCmpLogical"=dword:00000001
I don't. I want string sorting to be string sorting. Filenames are strings.
I wouldn't mind if there was an option to tell the file manager to do this "wrangle numbers out of strings and treat them as numbers" thing--so that I could turn that option off, and others who want that behavior could turn it on.
But for this to be the default, without even a way to change it (except in Dolphin, it looks like)? That seems daft to me.
Btw, I use Trinity Desktop, and I just verified that in TDE's version of Konqueror, the sorting of filenames is the same as for ls on the command line, e.g., 'item-10.txt' comes before 'item-9.txt'. Another good reason for me not to have switched to a more "modern" desktop.
> The author's situation is extremely rare
I don't think it is. But that's really beside the point. The computer is my tool. If it doesn't do what I want or expect it to do, it's a bad tool for me. And designers of tools shouldn't be making assumptions about how I want to use it. They should be giving me ways to tune it to how I want to use it.
> "mind-reading" is really helpful in ways we take for granted, like autosave.
I don't use autosave either. I don't want the computer to assume when I want to save a file. The computer is too stupid to know that.
> I don't use autosave either. I don't want the computer to assume when I want to save a file. The computer is too stupid to know that.
That’s why, with auto save systems, you flag/name a version as your canonical save point.
Rather like a video game, I’d rather have the autosaves and not need them, because I generally save the game myself, than not have them at all.
A computer can be helpful and obedient at the same time, when it’s done correctly and puts the user in control.
Perhaps put the uncommon (true alphanumerical order) behind a nested menu or something. But the mind-reading-less option should be there.
At least in KDE they are, and you can pick whether you want natural or alphabetical sorting (which has a case sensitive and insensitive variant).
People sorting their files for alphabetical order is extremely rare?
And right now I fail to see even one 'case where someone wants "10" to be before "9"'
I might go further in my ideal sorting algo which would be normalize capitalization and ignore all non-alphanumeric characters and treat them all as separators.
It is just that some users have conflicting needs and some sets of rules are more complex than others. So I think what this really is about is 'computer reading', the needs of some users to be able to predict with ease what the computer is going to do. Some people would rather be able to predict the computer doing something that they actually don't really need, and then make up for its shortcomings, than have something they feel they cannot predict and control, but is actually closer to what they want.
This is a bit like the term magic. Any sufficiently complex algorithm may indistinguishable from mind-reading, but it's still an algorithm. Mind-reading, like magic, depends on us being able to understand or not, which is highly subjective. But both are misleading terms.
Even if that were a valid reason for making it the default behavior, the real issue is they don't even give you the option to have the lexically correct sort order. They just decided to give you something that's not accurate and that's all you get.
A trend which is frustratingly, increasingly common.
It's trivial to allow customization behind menus. But we rarely get that anymore. Especially for sandboxes devices like phones.
It's a giant middle finger to users who want to actually use their devices as a tool, instead of simply a portal for more sales and marketing.
Your definition of "intuitive" would imply that innovation in intuition is impossible, which is evidently not true.
Nope, regarding what he talks about, the time was rose-tinted itself.
They are magic numbers. Maybe a serial ID, date stamp with more magic, revision, release, ...
Magic Number land has 10 > 9 in the above.
9 > 10 is only possible when removing the Magic Number and morph into mealiness text.
At the moment I cannot think of any magic number where 9 > 10.
Thankfully I'm using Total Commander and FastStone as a image organizer, neither of which have this bug in the sorting.
Give the user an option: have both "by name" lexicographic ordering, make it default by all means, but also provide a way to switch to an alphabetical order one for power users. Same applies to other features.
It is disappointing that apps and even some Linux Desktops today take the flexibility away from users, in the name of usability. By all means, I like and benefit from all the smart features, and I want them and will keep the on by default, but leave me an option to do the simpler, dumber and more predictable things too, for the case when I need to fallback to it.
https://news.ycombinator.com/item?id=27916370
The author wants the "worse" sort, one based on ASCII/Unicode codepoints, without any intelligence for numbers that 99% of GUI users want.
For their purposes, they've assumed something about the implementation, to the point that a convenience feature is actually a misfeature for them. But the author here is probably a developer, or close to one, so they do not represent the needs of most people using computers.
Understanding the target audience for your product results in very different design decisions. Better is better might be great for products, but worse is better is probably better for systems that need to grow and evolve.
I want the author's opinion on how caplital and lowercase letters should be sorted. Do they follow strict ASCII/Unicode codepoints, or do they normalize into actual alphabetical order and sort upper/lower within each letter?
I prefer the strict ASCII / Unicode sorting (all capitals first, then all lowercase).
> the target audience
Which is it? Those should be different groups.
"Most people" have incoherent ideas that can't even be used. So instead a designer cherry-picks some ideas - setting the agenda - and declares that they're popular. That doesn't make them good ideas. Also, "most people" are easily influenced and will like the terrible things that they've been told to like.
This is an excuse. Just add an option to sort both ways. It isn't hard.
There is no target audience in this planet that benefits from less options or less features. Even if you had the features under an "advanced mode" UI that's still a better software than not having the feature in first place.
Have people forgotten the 80/20 rule? Most features will be used by only a small slice of users, that doesn't mean they're out of scope.
Sorry, I'm just kind of exhausted of software not being able to do the most obvious things because it didn't align to some perfect vision of how the user should be.
I'm currently involved in UI design and, to my frustration, adding more options or features seems to send a vocal minority of the user base into a foaming-at-the-mouth violent rage. It's like any change resets the entire contents of their brain, and it's our fault we're making things so confusing for everyone...
And let's not get started on how we're wasting time adding things that they don't personally need, and therefore no one could possibly need, ever. No, clearly by adding this sorting method, we must have directly stolen development time from the feature they want, which is a personal attack directed at them and every member of their family going three generations back.
You can say that about every single design decision made about every product.
The gripe about this particular feature seems misplaced because almost all users will want the sort that's offered and the actual alphabetical sort is likely the desire of a more advanced user who, in fact, is offered a choice through registry editing and/or using a more advanced cli option for the occasion they might need an alternative sort.
This is a sensible default.
I actually don’t know exactly how it works internally and it is a little bit magical, but I use it all the time when looking through my files because it just sorta works in most cases. Of course a nice thing about it is easy to turn on or off.
The average user does not know the difference between lexical and alphabetic sort
I take it to mean they want the system to know file_9.txt is less then file_10.txt.
I never saw that happen in any OS, so I do not know what he is referring to. Maybe whatever that old system was, it sorted by create time as opposed to file name.
So, the author can try and create "aisort" that will look at all file names and add leading zeros to the file numeric portion, sort, then remove the zeros added. That will probably as slow as s***t and use gobs pf memory, depending on the number of files.
The polar opposite, actually.
Well, no. You don't actually ask them to sort in alphabetical order. You ask them to sort "by name", and that is up to their interpretation. And they choose the interpretation that (per their reasoning, and possibly some actual data) seems most likely to correspond to what the user wants.
Maybe future versions of those OSes will add a rule that says that if any of the number groups have leading zeros then it reverts back to actual alphabetic order. Or maybe they'll give you configurable options. (Maybe some of them already do.)
Yes, that make sense, but the problem is that this interpretation changed in the last 10 (15? 20?) years. It used to be that "by name" meant "by name, il alphabetical / lexicographical order" in pretty much every file manager.
Image-1.jpg
Image-11.jpg
Image-2.jpg
I wonder if there's an age divide at play here, where those of us who grew up with the naive alphabetical sort prefer it.
Anyone with experience expects them to work this way. Trying to be clever to cater to the inexperienced only harms both groups.
“There are additional complications in certain languages, where the comparison is context sensitive and depends on more than just single characters compared directly against one another,
[…]
Numbers. A customization may be desired to allow sorting numbers in numeric order. If strings including numbers are merely sorted alphabetically, the string “A-10” comes before the string “A-2”, which is often not desired. This behavior can be customized, but it is complicated by ambiguities in recognizing numbers within strings (because they may be formatted according to different language conventions). Once each number is recognized, it can be preprocessed to convert it into a format that allows for correct numeric sorting, such as a textual version of the IEEE numeric format.”*
I think those file browsers made the right choice, even given that they don’t (as in this example) always do the right thing.
my_photos_at_-3c
my_photos_at_-10c
Do users want smaller numbers first, or do they want them in counting order, away from zero?
> Well, apparently all these operating systems have decided that no, users are too dumb and they cannot possibly understand what alphabetical order means.
Google Drive uses ICU collation with the numeric option enabled, which treats each consecutive sequence of digits inside the filename as an integer. so "055436307" is parsed as the number 55,436,307, while "121134" is parsed as 121,134. and since 121,134 < 55,436,307 then "121134..." comes before "055436307..." even though lexicographic order would suggest the opposite. and i think when two digit runs have the same numeric value, the shorter run comes first; if runs are equal and the string continues, then normal character comparison resumes, including any underscores or suffixes
That said the author's situation where it's numerical and different lengths seems likely rare enough that it probably isn't worth complicating things.
The issue here is that one camera appends milliseconds to the seconds without a separator, and the other uses a separator.
So of course the ones that include milliseconds look like bigger numbers and get sorted last.
Leading zeros aren't the issue here.
(Good) "natural sort" implementations generally have ways of handling ties like this. It's similar to the problem of case-insensitive sort over case sensitive sets.
3ea4f...
...
97dce...
...
126b9...
I miss the time when computers did what you told them to, instead of trying to read your mind.
These days, it's more like "trying to change your mind". I absolutely hate the "the user is wrong" authoritarian mentality that unfortunately has infected a ton of software, even open-source.
[1] https://developer.apple.com/documentation/foundation/nsstrin...:)
[2] https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/...
I can’t think of any case where I would need purely alphabetical sort. In most photo browsing apps, photos will be sorted by timestamp rather than filename. If I really needed it to sort properly in file explorer, I would try sorting on created date. And failing that I would probably just normalize the file names.
The Finder sorts these as:
IMG_20250820_095716_607.jpg
IMG_20250820_103857_991.jpg
IMG_20250820_103903_811.jpg
IMG_20250820_055436307.jpg
IMG_20250820_092016029_HDR.jpg
IMG_20250820_092440966_HDR.jpg
IMG_20250820_092832138_HDR.jpg
IMG_20250820_055436307.jpg
IMG_20250820_092016029_HDR.jpg
IMG_20250820_092440966_HDR.jpg
IMG_20250820_092832138_HDR.jpg
IMG_20250820_095716_607.jpg
IMG_20250820_103857_991.jpg
IMG_20250820_103903_811.jpgIn true alphabetical sorting, sorting numbers is undefined behaviour. Both of these sorting methods are valid extensions of alphabetical sorting, and which you prefer is just that: a preference.
So actually when he says ‘alphabetical order’, he does not, in fact, mean ‘alphabetical order’.
Afaik there is no universal way to handle numbers in alphabetical lists. Sometimes numbers some before letters, sometimes after, etc.
A digit is not a part of the alphabet, right?
But it's actually not ASCII sorting either! ASCII sorting would mean 'Z' comes before 'a' and I assume even the author doesn't want that!
No matter what, there are going to be hidden tricks!
I don't know about the author, but that's exactly what many others who know about ASCII expect, including me. Digits, then uppercase, then lowercase.
But I'm a tech guy, I know what does "alphabetically" mean in the tech world. And it probably is not what common folks mean when they think "alphabetically" outside the tech world.
Edit: in fact, if I recall correctly, the proper term for this kind of sort (the one OP wants) is alphanumeric sort.
The natural numbers are ordered. Let me use its ordering instead of having to rely on an ad-hoc lexicographic fixed-length tuple representation of decimal digits, without any padding. My position is that numbers in filenames should always be considered atomically unless explicitly instructed otherwise.
If there were no issues of backwards compatibility, I would thus advocate for changing ls. Eza (maintained fork of Exa, Rust-based ls alternative) actually does sort this way by default, much to my delight.
1. Sync all equipments to the same clock.
2. Sort by Date Taken, if unavailable, sort by Date Created.
Did the author try "ls -v"? It would probably give the exact same order these file managers used.
I expect the same for other file managers on Linux. Although I must say I'm generally let down by Linux software.
> Unicode Technical Report #10 also specifies the Default Unicode Collation Element Table (DUCET). This data file specifies a default collation ordering.
https://en.wikipedia.org/wiki/Unicode_collation_algorithm
I assume this mainly aims at giving a reasonable compromise between the different dictionary and phone book sorting rules of various languages (and even locales), which should give reasonable results for most languages. I assume this also puts "Alice2" before "Alice10".
It doesn't (per https://www.unicode.org/reports/tr10/#Non-Goals):
> 1.9.2 Non-Goals
>
> The Default Unicode Collation Element Table (DUCET) explicitly does not provide for the following features:
> [ ... ]
> Numeric formatting: numbers composed of a string of digits or other numerics will not necessarily sort in numerical order.I found the magic two lines of Python to do a natural sort here, by the way: https://stackoverflow.com/questions/11150239/natural-sorting...
for i in $(seq 2 10) ; do
touch img_$i-hn.txt
done
ls img_* | sort -V
img_2-hn.txt
img_3-hn.txt
img_4-hn.txt
img_5-hn.txt
img_6-hn.txt
img_7-hn.txt
img_8-hn.txt
img_9-hn.txt
img_10-hn.txt
Edit: formatting and add sort -h
https://web.archive.org/web/20210207124255/http://www.daveko...
Even when files are enumerated it's pretty rare to have more than 9 parts and no zero-padding, whereas there are almost always multiple consecutive digits in the use cases for which "natural" sort is not a good fit for. It just feels like a bad default, at least for a programmer's workload.
I agree with you on this point.
> a datetime
AFAICT, natural sort shouldn't ever make datetimes harder to find, unless they are formatted inconsistently, as in the author's case. Suppose one camera wrote dates as 20250928 and another as 2025-09-28. ASCIIbetical sort would do nothing to help here.
Natural sort can even improve things over ASCII sort, for instance if someone is stuck with a format like "28/9/2025" or "September 2 2025"
The expected behaviour is ambiguous (and thus subjective). Older versions of windows shipped with alpha sort. New versions ship with natural alpha sort. According to the UX designers over at Microsoft (and surely the user feedback), natural sort _is_ the expected behaviour.
I certainly agree with natural sort being the expected behaviour too.
https://en.wikipedia.org/wiki/Natural_sort_order
It's simply natural sorting. I don't see what is so controversial about it.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Currentversion\Policies\Explorer\NoStrCmpLogical
I agree with the article.
I liked computers better when everyone hated them, and for the reasons they hated them..
Most of these decisions are early default behaviors that stay there as long as users aren't clamoring for change, and TBH I can't imagine most users to have a self emerging strong opinion on how alphabetical sort should be working.
8 5 4 9 1 7 6 3 2 0
Can you guess what it is?
U+0038 DIGIT EIGHT
...
U+0030 DIGIT ZERO
---
In all file managers, I miss an API point where one can give a userdefined sorting function for the file and folder list.
Regarding your second point, that's not really what a graphical file manager is for, I think. At this point (likely even earlier) you would be better off just writing a simple script in the scripting language of your choice. (If going for something fancy, you could also implement a FUSE based on symlinks for the original files, where the filename is prepended by a sort key. This would work for every major file manager and you could manipulate the files in mostly the same way as before.)
Usually preferable, except when not. Just like distinguishing between upper- and lowercase letters, and other misery.
When would it be preferable to distinguish between capital and lowercase letters?
Wiktionary does it religiously, and it always makes the entries worse. Want to know what something means in German? Well, that's on a separate page.
Do you want to look something up while using your phone? Don't be stupid; use a desktop that won't autocapitalize the first letter you type in.
> Digits and any other characters that are not A-Z and a-z should not get sorted.
Am I out of touch? No, it's the operating systems who are wrong
0 - numbers are not part of the alphabet.
KDE wins again. It's my favorite desktop environment, because it has defaults that are friendly to noobs, but it also get out of your way and lets you change things if you want.
The trend is for other desktop environments to be either/or. Either they are super simple and noob friendly, or they are super technical and have a steep learning curve and you get to configure everything - but only via text config. Maybe Cosmic looks like it's going the same route as KDE, where it's trying to bridge the gap.
For some inexplicable reason, Plex just throws its hand up on non-ASCII characters and puts them first.
In Norway we have three extra letters, æøå, and they're at the end of the alphabet after z. But in Plex, I have Øystein Sunde[1] placed before any other in my music library.
Now in the 1990s I would forgive US software for such a thing, but it's 2025...
if we don't have to collate as dictated by ascii, why should we expect users to live within the bounds of file names with dotted extensions? you think users care whether something is a jpg or a png? do users want to see .MOV and .mov next to each other (not because sort, because one camera programmer did it that way for an ancient DOS filesystem, and another didn't.) (unix, btw, never required that users live with dotted extensions, that was a digital knockoff/cpm/microsoft thing that you didn't understand so all your new tools enforce it even though you never had to put your code in a .c file, that was just for your convenience as the user whose needs must be respected)
so, we have to have "computery filenames" but we should violate "computery sorting"? how incredibly close-minded of you, you have no idea or basis to know what users want to see. oh, and the solemnity with which you make these proclamations, ok, don't get me started on that.
They absolutely do not care or understand the difference between alphabetical and numerical and natural, what they care about is 10 should not come before 9 in "Item 10" vs "Item 9".
Whatever pedantic argument you have that natural is not alphabetic will lose you sales, your users do not care and want numbers to make sense in sorting.
There is "Dictionary Order", "Phone book order", and a few other standards. (Dictionary order is not lexicographic order, even if the two are now commonly conflated).
A simple rule that most still know is a book titled "The Book", should be sorted under "Book, The".
They have variations on how special characters sort, how abbreviations are handled, and even have differences in numbers. For example, in phone book order, "21st Century" sorts under “Twenty-first”, not "21".
And, of course, non-English languages add all sorts of other rules.
This tends to get ignored these days, as lexical sorts are so much easier to implement, that people forget there are other, preferred options.
I am sure that at some point someone thought the milliseconds should or should not be separated from the seconds and made that change without thinking through the consequences.
I'm personally in the "want lexical as part of alphabetical" - as 'photo19' should come after 'photo2' in my expectations, but the number of cases cited where this doesn't/shouldn't work is enough to justify a degree of contextual or situation awareness that most systems and interfaces simply aren't designed to cater for (file-systems vs photo-storage applications).
Sort:
In Alphabetical Order
In Alphanumeric Order
In Alphabetic-Word Order
In Right-Aligned Alphabetic Order
Randomly
Sometimes
Never
By Hash
Very Fast
In the Background
In the Foreground
In the Underground
In the Cloud
Yes
With Bubbles
No Strong Opinion
Of
On YYYY-MM-DD HH-MM-SS: [SELECT] Repeat: [SELECT]
With Random Site Free Download Sort Extension: [SELECT]
Let Facebook
Emergency Backup Sort [SELECT]
Who Sort?(Which is wrong once the site doesn't update)
Needless to say, those are all "features" dumbing us down in the long run.
A philosophical side question: I want to opt out of this but I can't. So is this is case where my peers are limiting my intellectual development? I.e. preventing me from a) doing the time calculations in my head, b) writing my software such that is uses leading zeros?
You haven't seen anything yet. Get ready for "Sort by AI" which will try to interpret the content of your images to sort them based on what you'll want to look at next.
Incidentally, in this case AI would have sorted them the way you want:
These look like photos straight from a phone, with filenames in the form:
IMG_YYYYMMDD_HHMMSS...
So the natural way to sort them is *chronologically*, by the timestamp embedded in the filename.
If we do that, the order becomes:
1. `IMG_20250820_055436307.jpg` — Aug 20, 05:54:36
2. `IMG_20250820_092016029_HDR.jpg` — Aug 20, 09:20:16
3. `IMG_20250820_092440966_HDR.jpg` — Aug 20, 09:24:40
4. `IMG_20250820_092832138_HDR.jpg` — Aug 20, 09:28:32
5. `IMG_20250820_095716_607.jpg` — Aug 20, 09:57:16
6. `IMG_20250820_103857_991.jpg` — Aug 20, 10:38:57
7. `IMG_20250820_103903_811.jpg` — Aug 20, 10:39:03
That order reflects the actual sequence the photos were taken.If you haven't had to deal with it previously, you'd be flabbergasted at how many foot-guns there are in such a simple question as alphabetical sorting, even without involving numeric components in strings.
[1] There's no such thing as plain text https://www.youtube.com/watch?v=ajfb5LSbQVM
How did I find it? Well I wanted to implement it a while ago and I found it in Closure a library I was already using.
Your OCD is not my OCD.
Some people rushed to fix this as I'd done some diving into the issue and presented the relevant information and code, so now VSCode's Playwright test list uses the same sorting mechanism as the rest of VSCode.
Sadly, the underlying Playwright does not receive that order from VSCode so it still actually runs sequentially-numbered tests in strict alphabetical order. :(
i really really hate this framing, and i see it far too often. no, the operating system developers did not make a value judgement about their users. they observed their users to find out what behaviour was expected, and they designed the behaviour of the system to match the behaviour that the majority of users expect.
and then you made an incorrect assumption about how the system works, and decided that your incorrect assumption means everybody else is dumb and you're the only smart person in this situation?
No. Not “everyone understands that”. Natural sort happens in real life and everyone understands that. Only those who understand ASCII — not the average user of graphical file managers — will deduce the reason for your definition of “alphabetical order”.
> Now that I know what the issue is, I can solve it by renaming the files with a consistent scheme.
Intensely ironic given the previous suggestion.
This could be an illusion, or at least something difficult to evaluate; the operator is less likely to notice the situations when the computer successfully “reads their mind”.
Also, I guess new users (i.e. those unfamiliar with previous behavior) won’t care as much about wrong assumptions; they will only learn that one doesn’t need a leading zero.
I was joking. Really I would sort file names lexicographically. But the way Debian sorts version numbers is interesting and seems like a good way of handling that particular situation.
As an aside, this is also the reason why ISO 8601 is the best date format – it sorts the same way whether you do it alphabetically or lexicographically.
They don't even have an encoding you can use to sort something. Windows FileNames look like UTF-16, but they can be truncated. You can't convert them to UTF-8 and back without loss. (For that you need WTF-8)
Once you use random FileNames you'll start to notice...
Otherwise they mean lexicographical where they only look at the left most value and sort that.
You can't ask for something to be alphabetical and expect it to sort numerically.
The OS doesn't think you're too stupid to understand sorting, it relies on you being smart enough to figure out where the setting is located. In this case, four levels deep is probably too much to ask from users if they will write an entire blog post like this before finding the toggle.
If I remember correctly Windows 98 was sorting alphabetically. Then Windows XP strted to take numbers into consideration.
amen
It's like having a toddler help you make a meal. It wants to be involved and recognized so badly. Meanwhile I'm starving and just want to get the food done as quickly as is possible and I'm constantly tripping over this little ball of misguided efforts.
Please. Stop trying to be smarter than me. You often can't, and when you get it wrong, you make it measurably worse. If you insist on doing this please give me the "Expert Mode" setting back so I can flatly disable ALL OF IT with one click.
it is neither basic nor simple. Have you ever heard of UTF-8 and locales?
Here is an exercise for the curious reader: Pick any UTF-8 string "a", and another one "b", so that in increasing lexicographical order "a" sorts after "a+b" ("a" concatenated by "b"). ("a" > "a+b")
Call lexicographic order "sort by name" as it's called now, and call dumb character-by-character sort "plain" or something like that. I'm not a designer, maybe there are more intuitive names, but come on. This isn't an intractable problem.
Instead I have an order of starting character that goes 1,4,5,7,9,2,3,7,8,9,4,6,1,2,.. etc etc which is utterly useless as a sort. I've always thought the sort was weird but couldn't quite figure out why (I usually sort by date descending). Another non-productive thing to figure out and fix.
But it would frankly be great if most file browsers just let me sort photos based on metadata. But then I just end up in a dedicated photo browser, instead.
I think there are many things wrong with your assessment of the situation.
First, where does it say in these file managers that they're sorting by alphabetical order? I see that you've specified that you want the files sorted by name, but I don't see that you've specified you want them sorted by name alphabetically. And what does "alphabetical sort" even mean when you're sorting characters which are not letters? What you mean is probably "lexicographical sort".
Second, you admit yourself that users probably want natural sort. Why would you expect these products to do the thing which they know users usually don't want by default? That just seems like bad design to me. They know users usually want natural sort, and you know users usually want natural sort, so why would you expect the default behaviour to be a lexicographical sort?
Third, just like how you've learned to work around the lack of natural sort in poorly designed products of years past by adding leading zeroes, you can just add trailing zeroes to get the lexicographical ordering that you want. Why do you seem to be implying that the latter is more user-hostile than the former? It doesn't make sense to me. A decision had to be made about what sort to use and they picked the one that most people want. Isn't that what we should be expecting in a product that caters to its users?
I see in other comments you've suggested that there should be a separate option for choosing between lexicographical sort and natural sort. But in the past, when lexicographical sort was the only option, why weren't you complaining about it being user-hostile to only have one option then? Why is it only when the default is something you're personally not used to that it warrants complaint? And where do we stop, do we have separate controls for every single sortable string field to determine whether it should be sorted lexicographically or naturally? Or just the name field? Don't you think that is going to lead to interface bloat?
ls has it because it solves a real user need.
This makes it hard to find the file that was most recently changed, for example. Which is an action that is extremely common. (In fact, why does my file manager not have a most-recently-used shortcut?)
The International Components for Unicode library implements the Unicode Collation Algorithm, which depends on the language code and region of the locale, and looks up the quirks for each locale in the Common Locale Data Repository.
It's a much better idea to just use the standard ICU library or platform specific libraries (which are often build on ICU like JavaScript's Intl.Collator), instead of trying to hot dog it by rolling your own.
International Components for Unicode
https://en.wikipedia.org/wiki/International_Components_for_U...
>ICU provides the following services: Unicode text handling, full character properties, and character set conversions; Unicode regular expressions; full Unicode sets; character, word, and line boundaries; language-sensitive collation and searching; normalization, upper and lowercase conversion, and script transliterations; comprehensive locale data and resource bundle architecture via the Common Locale Data Repository (CLDR); multiple calendars and time zones; and rule-based formatting and parsing of dates, times, numbers, currencies, and messages.
Unicode Collation Algorithm
https://en.wikipedia.org/wiki/Unicode_collation_algorithm
>The Unicode collation algorithm (UCA) is an algorithm defined in Unicode Technical Report #10, which is a customizable method to produce binary keys from strings representing text in any writing system and language that can be represented with Unicode. These keys can then be efficiently compared byte by byte in order to collate or sort them according to the rules of the language, with options for ignoring case, accents, etc.[1]
>Unicode Technical Report #10 also specifies the Default Unicode Collation Element Table (DUCET). This data file specifies a default collation ordering. The DUCET is customizable for different languages,[1][2] and some such customizations can be found in the Unicode Common Locale Data Repository (CLDR).[3]
Common Locale Data Repository
https://en.wikipedia.org/wiki/Common_Locale_Data_Repository
>The Common Locale Data Repository (CLDR) is a project of the Unicode Consortium to provide locale data in XML format for use in computer applications. CLDR contains locale-specific information that an operating system will typically provide to applications. CLDR is written in the Locale Data Markup Language (LDML).
>Among the types of data that CLDR includes are the following:
Translations for language names
Translations for territory and country names
Translations for currency names, including singular/plural modifications
Translations for weekday, month, era, period of day, in full and abbreviated forms
Translations for time zones and example cities (or similar) for time zones
Translations for calendar fields
Patterns for formatting/parsing dates or times of day
Exemplar sets of characters used for writing the language
Patterns for formatting/parsing numbers
Rules for language-adapted collation
Rules for spelling out numbers as words
Rules for formatting numbers in traditional numeral systems (such as Roman and Armenian numerals)
Rules for transliteration between scripts, much of it based on BGN/PCGN romanization
sv-SE (Swedish): å, ä, ö are separate letters at the end of the alphabet, not variants of a or o.
de-DE (German): ä, ö, ü may sort as ae, oe, ue in some contexts, or as distinct letters. ß sometimes sorts as ss.
tr-TR (Turkish): dotted i (i) and dotless ı are different letters; I sorts with ı, not with i.
es-ES (Spanish): traditionally ch and ll were treated as single letters with their own place in the alphabet.
cs-CZ (Czech): ch still counts as a unique letter, sorted after h.
da-DK / no-NO (Danish/Norwegian): ø comes after z.
is-IS (Icelandic): þ (“thorn”) is part of the alphabet, after z.
fr-FR (French): accents usually ignored in sorting, so é = e, but not always depending on collation settings.
el-GR (Modern Greek): tonos accents, final sigma ς vs. σ, etc.
nl-NL (Dutch): the digraph “ij” is often treated as a single letter, and capitalized as “IJ”. In dictionaries and phone books it often sorts as a single letter under “I”, but sometimes is listed after “X” depending on tradition.
Then you get into non-Latin languages like, Chinese, Japanese, and Korean collation, which gets hairy with radicals, kana order, and stroke count.
Also different locales have different ways of representing numbers, like switching between "," and "." as separators and decimal points.
ICU supports integer only "natural" numeric collation, so anything more complicated like versions, floating point, negative numbers, hex, thousands separators, fractions, roman numerals, etc, you'd have to build on top of ICU.
ICU doesn't support incomprehensible dead languages like Latin or Ancient Greek (it does however support French ;). It does support Roman numeral formatting, but not collation, which would be pretty tricky and ambiguous.
https://www.youtube.com/watch?v=sKWvTlLMB-Y
A nuanced but common example that ICU/UCA/CLDR helps with is a menu to select the current locale: you have to translate each language's name into the current locale, and also sort them in the current locale. On top of different collations they can also have totally different spellings, like "United States of America" is "Verenigde Staten van Amerika" in Dutch. This makes it challenging for users to find their own language when the locale is set wrong! You just can't win.
Not to mention emojis! Which comes first: The chicken or the egg? The taco or the poop?
Also, the Mac Finder switches ":" and "/" for historical reasons (HFS used to use ":" as a directory separator instead of "/"), so you can create a file name like "9/11 Attack" in the Finder, which actually gets the underlying Unix filename "9:11 Attack". Don't believe me? Rename a file in the Finder to include a slash, which you know is impossible to represent as a Unix file name. Then go "ls" the directory in the shell.
The Mac Finder weirdly collates "/" after "9" because under the hood it’s really storing it as ":", which sorts before "0". But it also has other punctuation collating inconsistencies, sorting "," and ";" and others after "0" too. Definitely not ASCII order -- I'm not sure what rules it uses, but it's different than "ls".
However, while it's generally true you can't have "/" in Unix file names, NFS used to trustingly let clients rename Unix files to include a "/" in their name, which the Gator Box AppleTalk/Ethernet gateway let you do with the Mac Finder (pre OS/X), which would silently corrupt your "dump" backups on the Unix NFS server, so you would not learn about it until you tried to retrieve your files and "restore" crashed.
https://news.ycombinator.com/item?id=31821646
>Another reason that NFS sucks: Anyone remember the Gator Box? It enabled you to trick NFS into putting slashes into the names of files and directories, which seemed to work at the time, but came back to totally fuck you later when you tried to restore a dump of your file system.
>The NFS protocol itself didn't disallow slashes in file names, so the NFS server would accept them without question from any client, silently corrupting the file system without any warning. Thanks, NFS!
Not this keyboard not this chair, but the problem is with idiots between keyboards and chairs.
The author is not the ID10T it’s the other general users.
The author is intelligent enough to recognize that this is not alphabetical sort, but the term that they are looking for to describe the sort that they see in dolphin windows, google etc. is *lexical* sort, not alphabetical.
The engineering problem is ID10Tic not technical. How do you educate an illiterate public on what the difference between alphabetical and lexical sort is in practice?
You can’t, so you engineer around it and call lexical sort alphabetical.
Then if you want something to change, just ask the butler. If the app is open source and doesn't support the requested feature, the butler might even be able to code it up.