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:
> I rather think it's a non-starter, at least for Emacs 25.1.  It
> probably means users of all systems will be punished by slower
> directory searches,

How much slower do you suppose it would be? Especially for
utf-8, which I assume is fast anyway (it doesn't even seem to
reject excessively high codepoints... I'm not _entirely_ sure
utf-8 is not actually identical to emacs-internal, does anyone
know any concrete differences?)

Sometimes features, and correctness, have a performance cost. If
performance is the end-all and be-all priority, let's just
abolish all encodings and assume all filenames are in
emacs-internal.

What if it's only a 1% slow down? 5%? 10%? Or would an absolute
measure be more appropriate - i.e. define how much time it's
acceptable for it to take (on some standard directory and CPU).

> No, it's correctness on one platform vs speed on all the rest.

Strictly speaking, it's correctness for one encoding.

In trying to come up with another example, I noticed that in an
EUC-JP locale, typing "*修"TAB ("*\275\244") doesn't actually
match "文字化け" ["\312\270\273\372\262\275\244\261"] as I had
expected it to. I guess matching with embedded stars goes
through a different code path? Is there a way to simply enable
doing this for normal completion when the file system encoding
is utf-8-hfs? Or to add post-filtering [only return a filename
if it matches both the existing way *and* the decoded string
matches], only enabled by default on utf-8-hfs?

Or is even the time spent checking a boolean variable too much
of a performance penalty?