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