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

[Anders Lindgren]

> Below is a patch where I have dropped the old encoder and use the new instead.
> The only thing noteworthy is that `ucs-normalize' is loaded by loadup (when ns
> is used) and thus included in the dumped Emacs (if I understand correctly).
> Unless anybody objects, I'll push it in a couple of days.

Looks good to me, with one comment:

> diff --git a/lisp/loadup.el b/lisp/loadup.el
> index f0caa8b..dda433e 100644
> --- a/lisp/loadup.el
> +++ b/lisp/loadup.el
> @@ -276,6 +276,7 @@
>  (if (featurep 'ns)
>      (progn
>        (load "term/common-win")
> +      (load "international/ucs-normalize")
>        (load "term/ns-win")))
>  (if (fboundp 'x-create-frame)
>      ;; Do it after loading term/foo-win.el since the value of the
> diff --git a/lisp/term/ns-win.el b/lisp/term/ns-win.el
> index 0b3e3bd..9bd59fc 100644
> --- a/lisp/term/ns-win.el
> +++ b/lisp/term/ns-win.el
> @@ -51,6 +51,7 @@
>  (require 'menu-bar)
>  (require 'fontset)
>  (require 'dnd)
> +(require 'ucs-normalize)

Why do you need the 'require' if loadup will unconditionally load
ucs-normalize?

I was just trying to follow the pattern in ns-win.el, there are a number of requires at the beginning, after a comment saying ";; Documentation-purposes only: actually loaded in loadup.el."

I can easily drop the line, if you think it's better.

> > After giving this some thought, it feels like the file name matching should be
> > done on decoded strings (so that an "a" doesn't match the "a" in a decomposed
> > "å"). However, this is a major change and needs to be discussed further.
>
> 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, on behalf of one peculiar filesystem.  Unless
> there's some clever idea that avoids decoding each file name returned
> by readdir, that is.

The eternal question of correctness versus speed...

My gut feeling is that the time it takes to decode the file names is dwarfed by the time it takes to read the file list from the harddisk (this needs to be verified, of course). In addition, for systems like Linux, encoding and decoding are no-ops (as both the source and destination is UTF-8), so there won't be a penalty there.

I agree that this is not a project for Emacs 25.1 -- however, I think that we should at explore this for future versions. I suggest that we push the current patch (after dropping the `require' line), close the current issue, and post a new bug report suggesting performing the completion on decoded strings.

    -- Anders