3 ms·

But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today.

But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today. But of course there is a place for improvement (dealing with accented letters in European languages, dealing with combining characters, different alphabets like Hiragana/Katakana etc).

forty 5y ago
Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).
- codedokode 5y ago
  It is "simple" for a programmer who doesn't want to learn Unicode and prefers working with bytes instead of letters, but inconvenient for a user. More keypresses, easier to make a mistake when typing. I cannot imagine a situation where you need two files whose names differ only in case.
  - forty 5y ago
    Since it's relevant and funny, I'll quote the famous rant of Linus Torvalds on the topic (it was because of issues it caused with Git, but I assume it still means it's unlikely Linux will ever follow this path ^^) "The true horrors of HFS+ are not in how it’s not a great filesystem, but in how it’s actively designed to be a bad filesystem by people who thought they had good ideas. The case insensitivity is just a horribly bad idea, and Apple could have pushed fixing it. They didn’t. Instead, they doubled down on a bad idea, and actively extended it – very very badly – to unicode. And it’s not even UTF-8, it’s UCS2 I think. Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+. There’s some excuse for case insensitivity in a legacy model (“We didn’t know better”). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn’t be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They’ll be happy, and they won’t be messing up your system. And then picking NFD normalization – and making it visible, and actively converting correct unicode into that absolutely horrible format, that’s just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It’s not even “paste-eater” quality thinking. It’s actually actively corrupting user data. By design. Christ. And Apple let these monkeys work on their filesystem? Seriously?"
  - galaxyLogic 5y ago
    I can think of one. When we write (say "ES6") modules it makes sense that the name of the module-file without extension should be the same as the value exported by that module. Inside the module you'd prefer to follow conventions like name classes title-case and name functions camel-case. Thus you might have one module exporting a class named "Camel", and another module exporting a function named "camel". You could then have two files, Camel.js, and camel.js in the same directory, containing two separate programs.
kps 5y ago
> If you simply use Unicode-aware version of "to lowercase" function […] There's no such thing. What's the lowercase of ‘I’ — ‘i’ or ‘ı’?
- Dylan16807 5y ago
  That's the "place for improvement" you shoved into the "[...]". Pick something.
  - kps 5y ago
    Pick something? Whatever you pick is wrong for some users.
    - Dylan16807 5y ago
      And busted unicode support is more wrong. Also you don't need to have an opinion on how to lowercase, you can just say that İIiı are equivalent and it shouldn't make people that upset.

forty 5y ago

Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).

codedokode 5y ago
It is "simple" for a programmer who doesn't want to learn Unicode and prefers working with bytes instead of letters, but inconvenient for a user. More keypresses, easier to make a mistake when typing. I cannot imagine a situation where you need two files whose names differ only in case.
- forty 5y ago
  Since it's relevant and funny, I'll quote the famous rant of Linus Torvalds on the topic (it was because of issues it caused with Git, but I assume it still means it's unlikely Linux will ever follow this path ^^) "The true horrors of HFS+ are not in how it’s not a great filesystem, but in how it’s actively designed to be a bad filesystem by people who thought they had good ideas. The case insensitivity is just a horribly bad idea, and Apple could have pushed fixing it. They didn’t. Instead, they doubled down on a bad idea, and actively extended it – very very badly – to unicode. And it’s not even UTF-8, it’s UCS2 I think. Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+. There’s some excuse for case insensitivity in a legacy model (“We didn’t know better”). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn’t be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They’ll be happy, and they won’t be messing up your system. And then picking NFD normalization – and making it visible, and actively converting correct unicode into that absolutely horrible format, that’s just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It’s not even “paste-eater” quality thinking. It’s actually actively corrupting user data. By design. Christ. And Apple let these monkeys work on their filesystem? Seriously?"
- galaxyLogic 5y ago
  I can think of one. When we write (say "ES6") modules it makes sense that the name of the module-file without extension should be the same as the value exported by that module. Inside the module you'd prefer to follow conventions like name classes title-case and name functions camel-case. Thus you might have one module exporting a class named "Camel", and another module exporting a function named "camel". You could then have two files, Camel.js, and camel.js in the same directory, containing two separate programs.

kps 5y ago

> If you simply use Unicode-aware version of "to lowercase" function […] There's no such thing. What's the lowercase of ‘I’ — ‘i’ or ‘ı’?

Dylan16807 5y ago
That's the "place for improvement" you shoved into the "[...]". Pick something.
- kps 5y ago
  Pick something? Whatever you pick is wrong for some users.
  - Dylan16807 5y ago
    And busted unicode support is more wrong. Also you don't need to have an opinion on how to lowercase, you can just say that İIiı are equivalent and it shouldn't make people that upset.