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

View this message in rfc822 format

From: Random832 <random832 <at> fastmail.com>
To: 22169 <at> debbugs.gnu.org
Subject: bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X
Date: Fri, 18 Dec 2015 10:42:31 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:
>   . modern OSes cache this stuff, so you can do that without ever
>     hitting the disk

*ever*? Surely at least once.

>   . many modern machines have SSDs (mine does), where disk drive
>     accesses, even when they are needed, are very fast

They're fast, yes, but my own gut feeling is that they're not
actually fast *enough* not to be the bottleneck.

>   . by contrast, decoding a non-trivial encoding might take many CPU
>     cycles, especially in the utf-8-hfs case, where we call Lisp as
>     part of that

I don't know why "especially in the utf-8-hfs case" - the
current code is no more correct for utf-8-hfs on Linux than for
utf-8-hfs on OSX.

> Yes, but only in UTF-8 locales.  I won't be surprised to learn that
> most of Far East uses something else, even on GNU/Linux.  And then
> there are Windows volumes mounted via NFS and such likes.

I think most people who do this (I should think it would be
SMB/CIFS rather than NFS - if it's really NFS then I suppose the
translation has to happen on the Windows side) have the file-
system translated to UTF-8 [etc] for them by the kernel.  There
are mount options "iocharset" and "codepage" (the latter for the
filesystem's coding system on 8-bit filesystems), to take care
of this.  Working with multiple different directories with
different filename encoding systems is a pathological case, and
one which as far as I know Emacs makes no attempt to deal with
(except by the user switching manually).

Previous Next

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