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

[Random832 <random832@fastmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:
> I certainly see a pre-write-conversion function in ucs-normalize.el:
> ucs-normalize-hfs-nfd-pre-write-conversion which calls
> ucs-normalize-HFS-NFD-region.  So I'm not sure I understand what you
> are saying.

I was talking about the "utf-8-nfd" encoding in ns-win.el. I'd
missed the statement that the problem had been reproduced with
utf-8-hfs.

I can't actually reproduce the problem myself with utf-8-hfs.  I
thought I had it once, but only immediately after switching from
utf-8-nfd (maybe the bad completion result from utf-8-nfd was in
some kind of cache?), and now I can't even reproduce that.
Otherwise, it seems to fix the problem.  Anders, can you try
this again from a clean emacs -Q session, and in particular load
ucs-normalize and set the coding system to utf-8-hfs _before_
attempting any completion?

--

Incidentally, I do get one other bit of bizarre behavior
associated with this.  If I have multiple files that start with
the same base letter and different (or no) accents, pressing TAB
_deletes_ that letter.  E.g. files: à1 á2 a3.  C-x C-f a TAB,
deletes the "a". I'd expect it to either offer all three
filenames, or just a3.

Why exactly does completion do matching with encoded prefix
against raw filenames, rather than with unicode prefix against
decoded filenames, anyway?