From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X Date: Fri, 18 Dec 2015 19:06:25 +0200 Message-ID: <83k2obwusu.fsf@gnu.org> 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> <87lh8rpykm.fsf@fastmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1450459144 5213 80.91.229.3 (18 Dec 2015 17:19:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Dec 2015 17:19:04 +0000 (UTC) Cc: 22169@debbugs.gnu.org To: Random832 Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 18 18:18:53 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 1a9yg8-0008Jh-5I for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Dec 2015 18:18:52 +0100 Original-Received: from localhost ([::1]:34109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9yg7-0001KQ-Ag for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Dec 2015 12:18:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9yUj-0003Q6-72 for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2015 12:07:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9yUg-0002yN-0G for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2015 12:07:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9yUf-0002yH-PF for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2015 12:07:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a9yUf-00035P-Kq for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2015 12:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Dec 2015 17:07:01 +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.145045837311805 (code B ref 22169); Fri, 18 Dec 2015 17:07:01 +0000 Original-Received: (at 22169) by debbugs.gnu.org; 18 Dec 2015 17:06:13 +0000 Original-Received: from localhost ([127.0.0.1]:55924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9yTs-00034L-Pe for submit@debbugs.gnu.org; Fri, 18 Dec 2015 12:06:12 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47268) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9yTr-000348-Iw for 22169@debbugs.gnu.org; Fri, 18 Dec 2015 12:06:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9yTj-0002hi-5R for 22169@debbugs.gnu.org; Fri, 18 Dec 2015 12:06:06 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9yTj-0002he-2X; Fri, 18 Dec 2015 12:06:03 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1964 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1a9yTi-0008G7-7t; Fri, 18 Dec 2015 12:06:02 -0500 In-reply-to: <87lh8rpykm.fsf@fastmail.com> (message from Random832 on Fri, 18 Dec 2015 10:26:49 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:110136 Archived-At: > From: Random832 > Date: Fri, 18 Dec 2015 10:26:49 -0500 > > Eli Zaretskii writes: > > I rather think it's a non-starter, at least for Emacs 25.1. It > > probably means users of all systems will be punished by slower > > directory searches, > > How much slower do you suppose it would be? I don't know. That's why I suggested timing it. > I'm not _entirely_ sure utf-8 is not actually identical to > emacs-internal It isn't. > does anyone know any concrete differences? Raw bytes and characters from Far-Eastern charsets that are not unified get non-trivial conversions. > Sometimes features, and correctness, have a performance cost. If > performance is the end-all and be-all priority, let's just > abolish all encodings and assume all filenames are in > emacs-internal. We need to know the cost before we make the decision. It could be that you are right and the cost is negligible, then the decision will be very easy. But it also could be not so easy. > In trying to come up with another example, I noticed that in an > EUC-JP locale, typing "*修"TAB ("*\275\244") doesn't actually > match "文字化け" ["\312\270\273\372\262\275\244\261"] as I had > expected it to. I guess matching with embedded stars goes > through a different code path? I'm not familiar enough with all the high-level tricks above the dired.c primitives that were introduced lately. I hope someone else will answer that. (You could try figuring that out by looking at the calls to file_name_completion that are done by Lisp.) > Is there a way to simply enable doing this for normal completion > when the file system encoding is utf-8-hfs? Or to add post-filtering > [only return a filename if it matches both the existing way *and* > the decoded string matches], only enabled by default on utf-8-hfs? The latter is what I had in mind, yes. > Or is even the time spent checking a boolean variable too much > of a performance penalty? No, I don't think so.