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

[Anders Lindgren]

Hi!

Unfortunately, it still doesn't work, the "a" is still deleted. You can see what happens here:

(file-name-all-completions "" ".")

("åäö.txt" "aao.txt" "../" "./")

(file-name-all-completions "a" ".")

("åäö.txt" "aao.txt")                     <= Incorrect result

(file-name-all-completions "å" ".")

("åäö.txt")

I gave this a bit of thinking, would the following work:

 - For each match of the current system (using encoded comparison), after the decoding of the entry, perform a second comparison with the decoded (original) version of "file" (when not empty).

There is no extra decoding included, as the number of entries decoded is the same as before (even if some entries will be rejected now). The extra comparison is only performed if "file" is not empty, so it will not affect normal directory retrieval, only when performing a completion operation.

Concretely, in the example above, completing "a" will find both entries which are decoded. However, the second comparison will reject "åäö.txt".

    -- Anders

On Sun, Dec 20, 2015 at 6:56 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Date: Fri, 18 Dec 2015 09:07:39 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: random832@fastmail.com, 22169@debbugs.gnu.org
>
> > 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.
>
> I have an idea for a change that could solve this.  I will post it in
> a day or two and ask you to try it.

Could you please try the patch below, and see if it avoids the "lax"
matches and the confusing effect of deleting "a" in the scenario above
is avoided on OS X?

(This is not the full patch, since we need to add this code only for
some file-name encodings, such as utf-8-hfs.  If this works for you, I
will add the missing bits.  If it doesn't work, please tell where I
goofed.)

Thanks.

diff --git a/src/dired.c b/src/dired.c
index 84bf247..4ff85f1 100644
--- a/src/dired.c
+++ b/src/dired.c
@@ -641,16 +641,30 @@ file_name_completion (Lisp_Object file, Lisp_Object dirname, bool all_flag,

       matchcount += matchcount <= 1;

+      Lisp_Object zero = make_number (0);
       if (all_flag)
-       bestmatch = Fcons (name, bestmatch);
+       {
+         Lisp_Object cmp1
+           = Fcompare_strings (name, zero, make_number (SCHARS (name)),
+                               file, zero, make_number (SCHARS (file)),
+                               completion_ignore_case ? Qt : Qnil);
+         if (EQ (cmp1, Qt) || XINT (cmp1) != -1)
+           bestmatch = Fcons (name, bestmatch);
+       }
       else if (NILP (bestmatch))
        {
-         bestmatch = name;
-         bestmatchsize = SCHARS (name);
+         Lisp_Object cmp2
+           = Fcompare_strings (name, zero, make_number (SCHARS (name)),
+                               file, zero, make_number (SCHARS (file)),
+                               completion_ignore_case ? Qt : Qnil);
+         if (EQ (cmp2, Qt) || XINT (cmp2) != -1)
+           {
+             bestmatch = name;
+             bestmatchsize = SCHARS (name);
+           }
        }
       else
        {
-         Lisp_Object zero = make_number (0);
          /* FIXME: This is a copy of the code in Ftry_completion.  */
          ptrdiff_t compare = min (bestmatchsize, SCHARS (name));
          Lisp_Object cmp