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

[Eli Zaretskii <eliz@gnu.org>]

> From: Random832 <random832@fastmail.com>
> Date: Fri, 18 Dec 2015 10:26:49 -0500
> 
> 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?

I don't know.  That's why I suggested timing it.

> I'm not _entirely_ sure utf-8 is not actually identical to
> emacs-internal

It isn't.

> does anyone know any concrete differences?

Raw bytes and characters from Far-Eastern charsets that are not
unified get non-trivial conversions.

> 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.

We need to know the cost before we make the decision.  It could be
that you are right and the cost is negligible, then the decision will
be very easy.  But it also could be not so easy.

> 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?

I'm not familiar enough with all the high-level tricks above the
dired.c primitives that were introduced lately.  I hope someone else
will answer that.  (You could try figuring that out by looking at the
calls to file_name_completion that are done by Lisp.)

> 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?

The latter is what I had in mind, yes.

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

No, I don't think so.