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

Previous Next

Package: emacs;

Reported by: Anders Lindgren <andlind <at> gmail.com>

Date: Mon, 14 Dec 2015 19:09:01 UTC

Severity: normal

Found in version 25.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Random832 <random832 <at> fastmail.com>
To: bug-gnu-emacs <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 10:26:49 -0500
Eli Zaretskii <eliz <at> gnu.org> 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? Especially for
utf-8, which I assume is fast anyway (it doesn't even seem to
reject excessively high codepoints... I'm not _entirely_ sure
utf-8 is not actually identical to emacs-internal, does anyone
know any concrete differences?)

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.

What if it's only a 1% slow down? 5%? 10%? Or would an absolute
measure be more appropriate - i.e. define how much time it's
acceptable for it to take (on some standard directory and CPU).

> No, it's correctness on one platform vs speed on all the rest.

Strictly speaking, it's correctness for one encoding.

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

Or is even the time spent checking a boolean variable too much
of a performance penalty?





This bug report was last modified 9 years and 154 days ago.

Previous Next


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