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

Previous Next

Full log

Message #80 received at 22169 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: 22169 <at> debbugs.gnu.org
Cc: random832 <at> fastmail.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#22169: 25.0.50; File name compiletion doesn't work with
 non-ASCII characters on OS X
Date: Fri, 18 Dec 2015 07:29:17 +0100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.