From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X Date: Sun, 20 Dec 2015 20:16:29 +0100 Message-ID: References: <83y4cw3kie.fsf@gnu.org> <83twnk3fg1.fsf@gnu.org> <83oads2x99.fsf@gnu.org> <83io3z3drh.fsf@gnu.org> <831tan32q2.fsf@gnu.org> <83r3ikxmis.fsf@gnu.org> <83fuyxt35q.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114405c6b1c46105275935e2 X-Trace: ger.gmane.org 1450639045 16113 80.91.229.3 (20 Dec 2015 19:17:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Dec 2015 19:17:25 +0000 (UTC) Cc: random832@fastmail.com, 22169@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 20 20:17:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aAjTk-0007B2-P6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Dec 2015 20:17:13 +0100 Original-Received: from localhost ([::1]:41755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAjTj-0000v6-QK for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Dec 2015 14:17:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAjTe-0000uA-NW for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2015 14:17:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAjTa-0007KB-L4 for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2015 14:17:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAjTa-0007K7-Hs for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2015 14:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aAjTa-000301-8P for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2015 14:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Dec 2015 19:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22169 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22169-submit@debbugs.gnu.org id=B22169.145063899711494 (code B ref 22169); Sun, 20 Dec 2015 19:17:02 +0000 Original-Received: (at 22169) by debbugs.gnu.org; 20 Dec 2015 19:16:37 +0000 Original-Received: from localhost ([127.0.0.1]:58218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aAjTB-0002zJ-1Q for submit@debbugs.gnu.org; Sun, 20 Dec 2015 14:16:37 -0500 Original-Received: from mail-vk0-f51.google.com ([209.85.213.51]:32837) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aAjT9-0002z4-Gl for 22169@debbugs.gnu.org; Sun, 20 Dec 2015 14:16:35 -0500 Original-Received: by mail-vk0-f51.google.com with SMTP id a188so91620210vkc.0 for <22169@debbugs.gnu.org>; Sun, 20 Dec 2015 11:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VwYOt3C/fbWgoMJGIrPvqUsRuaAgIJkk3so34oE0CWg=; b=PJAETFN5/f4Ypu7FLYHCWMHWJFhNoAAuO/0GaS3qQsmGWuqr3WX/QukejbE4GRv5RG oyuiZ1UFEgBcTXCv6dNTi9n+KTHnLxvvjKf1DmrikoXpALj2Qvz4c6rvo4Lw+s0SpHFg v9DN7g/EczJx6vnvzng+q/P6jrQ28xfSocDVA9AL5XvMeNALV8OOhXrmydwMIoFvtuzm YyWxdM2byyh5rDKVIf7LSGUWBr067UwHk0/wtSntMhmAJsNmM9SDVbszAS+K1vYa+GTD V30rxbjjQLvjqO33P4AGLq6Me5fR8DjB9alL7MRJaAmypxGyuQFuoe+H/3qEqNHK4dMY YEbQ== X-Received: by 10.31.58.74 with SMTP id h71mr9873741vka.149.1450638989966; Sun, 20 Dec 2015 11:16:29 -0800 (PST) Original-Received: by 10.31.210.133 with HTTP; Sun, 20 Dec 2015 11:16:29 -0800 (PST) In-Reply-To: <83fuyxt35q.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:110212 Archived-At: --001a114405c6b1c46105275935e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! Unfortunately, it still doesn't work, the "a" is still deleted. You can see what happens here: (file-name-all-completions "" ".") ("=C3=A5=C3=A4=C3=B6.txt" "aao.txt" "../" "./") (file-name-all-completions "a" ".") ("=C3=A5=C3=A4=C3=B6.txt" "aao.txt") <=3D Incorrect res= ult (file-name-all-completions "=C3=A5" ".") ("=C3=A5=C3=A4=C3=B6.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 "=C3=A5=C3=A4= =C3=B6.txt". -- Anders On Sun, Dec 20, 2015 at 6:56 PM, Eli Zaretskii wrote: > > Date: Fri, 18 Dec 2015 09:07:39 +0200 > > From: Eli Zaretskii > > Cc: random832@fastmail.com, 22169@debbugs.gnu.org > > > > > After reading through Random832:s comments, I also see the problem > with "=C3=A5=C3=A4=C3=B6" > > > and "aao" not being handled correctly. Typing "a TAB" makes Emacs > delete the > > > "a", which seems very confusing. Typing "=C3=A5 TAB" or "aa TAB" work= s, > though. > > > (Here `(file-name-all-completions "a" ".")' returns `("=C3=A5=C3=A4= =C3=B6first.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 "=C3=A5" 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 +=3D matchcount <=3D 1; > > + Lisp_Object zero =3D make_number (0); > if (all_flag) > - bestmatch =3D Fcons (name, bestmatch); > + { > + Lisp_Object cmp1 > + =3D 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) !=3D -1) > + bestmatch =3D Fcons (name, bestmatch); > + } > else if (NILP (bestmatch)) > { > - bestmatch =3D name; > - bestmatchsize =3D SCHARS (name); > + Lisp_Object cmp2 > + =3D 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) !=3D -1) > + { > + bestmatch =3D name; > + bestmatchsize =3D SCHARS (name); > + } > } > else > { > - Lisp_Object zero =3D make_number (0); > /* FIXME: This is a copy of the code in Ftry_completion. */ > ptrdiff_t compare =3D min (bestmatchsize, SCHARS (name)); > Lisp_Object cmp > --001a114405c6b1c46105275935e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

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

(file-name-all-completions "" "= .")
("=C3=A5=C3=A4=C3=B6.txt" "aao.txt" = "../" "./")

(file-name-all-com= pletions "a" ".")
("=C3=A5=C3=A4=C3=B6.t= xt" "aao.txt") =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <=3D Incorrect result

= (file-name-all-completions "=C3=A5" ".")
(&qu= ot;=C3=A5=C3=A4=C3=B6.txt")


<= div>I gave this a bit of thinking, would the following work:

=
=C2=A0- For each match of the current system (using encoded comp= arison), after the decoding of the entry, perform a second comparison with = the decoded (original) version of "file" (when not empty).
<= div>
There is no extra decoding included, as the number of en= tries decoded is the same as before (even if some entries will be rejected = now). The extra comparison is only performed if "file" is not emp= ty, 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 "=C3=A5=C3=A4=C3=B6.txt&quo= t;.

=C2=A0 =C2=A0 -- Anders

On Sun, Dec 20, 2015 at 6:5= 6 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 proble= m with "=C3=A5=C3=A4=C3=B6"
> > and "aao" not being handled correctly. Typing "a T= AB" makes Emacs delete the
> > "a", which seems very confusing. Typing "=C3=A5 TA= B" or "aa TAB" works, though.
> > (Here `(file-name-all-completions "a" ".")= 9; returns `("=C3=A5=C3=A4=C3=B6first.txt"
> > "aaosecond.txt")'.
> >
> > In other words, Emcas is in better shape with my than it was befo= re, but there
> > is still some work to be done.
> >
> > When it comes to "lax" matching -- I really don't t= hink we should use it for
> > file names. I don't want to match "=C3=A5" when I t= ype "a" etc.
>
> I have an idea for a change that could solve this.=C2=A0 I will post i= t 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.=C2=A0 If this works for you, I=
will add the missing bits.=C2=A0 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 d= irname, bool all_flag,

=C2=A0 =C2=A0 =C2=A0 =C2=A0matchcount +=3D matchcount <=3D 1;

+=C2=A0 =C2=A0 =C2=A0 Lisp_Object zero =3D make_number (0);
=C2=A0 =C2=A0 =C2=A0 =C2=A0if (all_flag)
-=C2=A0 =C2=A0 =C2=A0 =C2=A0bestmatch =3D Fcons (name, bestmatch);
+=C2=A0 =C2=A0 =C2=A0 =C2=A0{
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lisp_Object cmp1
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D Fcompare_strings (name, zero,= make_number (SCHARS (name)),
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0file, zero, make_number (SCHARS (file= )),
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0completion_ignore_case ? Qt : Qnil);<= br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (EQ (cmp1, Qt) || XINT (cmp1) !=3D -1= )
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bestmatch =3D Fcons (name, bestma= tch);
+=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0else if (NILP (bestmatch))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bestmatch =3D name;
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bestmatchsize =3D SCHARS (name);
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lisp_Object cmp2
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D Fcompare_strings (name, zero,= make_number (SCHARS (name)),
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0file, zero, make_number (SCHARS (file= )),
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0completion_ignore_case ? Qt : Qnil);<= br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (EQ (cmp2, Qt) || XINT (cmp2) !=3D -1= )
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bestmatch =3D name;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bestmatchsize =3D SCHARS (= name);
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lisp_Object zero =3D make_number (0); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* FIXME: This is a copy of the code in = Ftry_completion.=C2=A0 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ptrdiff_t compare =3D min (bestmatchsize= , SCHARS (name));
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lisp_Object cmp

--001a114405c6b1c46105275935e2--