bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X

[Random832]

Eli Zaretskii <eliz@gnu.org> writes:
>   . modern OSes cache this stuff, so you can do that without ever
>     hitting the disk

*ever*? Surely at least once.

>   . many modern machines have SSDs (mine does), where disk drive
>     accesses, even when they are needed, are very fast

They're fast, yes, but my own gut feeling is that they're not
actually fast *enough* not to be the bottleneck.

>   . by contrast, decoding a non-trivial encoding might take many CPU
>     cycles, especially in the utf-8-hfs case, where we call Lisp as
>     part of that

I don't know why "especially in the utf-8-hfs case" - the
current code is no more correct for utf-8-hfs on Linux than for
utf-8-hfs on OSX.

> Yes, but only in UTF-8 locales.  I won't be surprised to learn that
> most of Far East uses something else, even on GNU/Linux.  And then
> there are Windows volumes mounted via NFS and such likes.

I think most people who do this (I should think it would be
SMB/CIFS rather than NFS - if it's really NFS then I suppose the
translation has to happen on the Windows side) have the file-
system translated to UTF-8 [etc] for them by the kernel.  There
are mount options "iocharset" and "codepage" (the latter for the
filesystem's coding system on 8-bit filesystems), to take care
of this.  Working with multiple different directories with
different filename encoding systems is a pathological case, and
one which as far as I know Emacs makes no attempt to deal with
(except by the user switching manually).