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

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]

Hi!

I just realized that I missed parts of the ongoing discussion -- I was
under impression that I as OP should be CC:ed, but apparently I wasn't.

After reading through Random832:s comments, I also see the problem with
"åäö" and "aao" not being handled correctly. Typing "a TAB" makes Emacs
delete the "a", which seems very confusing. Typing "å TAB" or "aa TAB"
works, though. (Here `(file-name-all-completions "a" ".")' returns
`("åäöfirst.txt" "aaosecond.txt")'.

In other words, Emcas is in better shape with my than it was before, but
there is still some work to be done.

When it comes to "lax" matching -- I really don't think we should use it
for file names. I don't want to match "å" when I type "a" etc.

HFS+ file systems are case sensitive (It's possible this can be disabled,
but if so it's very rarely used). However,  many OS X desktop applications
work hard to make this invisible to users. I think that we should keep
`read-file-name-completion-ignore-case' as it is, as this corresponds to
how files really are stored.

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.

    -- Anders

On Thu, Dec 17, 2015 at 11:01 PM, Anders Lindgren <andlind@gmail.com> wrote:
>
> Hi!
>
> I think I have solved this.
>
> The current coding system defined in ns-win.el didn't work because it
only provided a decode but no encode functions.
>
> After revisiting the "hfs" encoder, I managed to get it to work, this
time.
>
> 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.
>
>     -- Anders
>
> On Tue, Dec 15, 2015 at 9:05 PM, Anders Lindgren <andlind@gmail.com>
wrote:
>>
>> Hi,
>>
>>>
>>> Can you write a patch to that effect, for emacs-25 branch?
>>
>>
>> We have the find the cause of the problem first. But once we do that,
this should be straight forward.
>>
>>
>>> >     What does this return:
>>> >
>>> >     M-: (file-name-all-completion "åäö" "/that/empty/directory/") RET
>>> >
>>> > It returns nil.
>>>
>>> So this is the heart of the problem.  I assume that if you do the same
>>> with an ASCII first argument, the result is non-nil, yes?
>>
>>
>> Yes.
>>
>>
>>>
>>> Then the next step is to step with a debugger through
>>> file_name_completion, and see why this returns nil instead of a list
>>> of files that begin.
>>
>>
>> Auhm, I'll see what I can do. I'm a family father and have very, very,
limited time, but I can see in I can find a time slot for it.
>>
>>     -- Anders
>>
>

[-- Attachment #2: Type: text/html, Size: 3712 bytes --]