Re: Unicode, Korean, normalization form, Mac OS X and tab completion

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Bart Schaefer wrote on Sun, Jun 01, 2014 at 00:56:24 -0700:
> On Jun 1,  2:25am, Daniel Shahaf wrote:
> } FWIW, while OS X always returns NFD filenames, one could also imagine an
> } OS that is normalization-aware (forbids creating a file if its
> } normalized name is the same as the normalized name of an existing file)
> } but octet-sequence-preserving, and on such an OS both the readdir()
> } output and the user input would need to be normalized.
> 
> This case is ultimately the same as your first example.  Either the two
> forms of name should be treated the same, in which case normalizing the
> results of readdir() is enough, or they should be treated as different
> even though you aren't allowed to create both of them, in which case
> they should not be normalized at all (and then there better be some way
> outside the shell, e.g., at the TTY driver layer, to choose the input
> encoding).
> 
> Maybe the completion system should use (#u) more often, or maybe there
> needs to be a setopt to cause all patterns to act as if (#u) ...
> 
> If there's a tricky bit, it's knowing which encoding is the default for
> input so you can normalize to that one.

Well, sure, if the user input is normalized to NFC before it hits zsh,
then the problem is simpler (either NFC->NFD the input or NFD->NFC
readdir).  I was trying to solve the more general problem of matching
non-normalized readdir output to non-normalized user input; perhaps
that would be an overkill.

Daniel