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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 22169 <at> debbugs.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 11:15:29 +0200

> Date: Fri, 18 Dec 2015 09:38:08 +0100
> From: Anders Lindgren <andlind <at> gmail.com>
> Cc: 22169 <at> debbugs.gnu.org
> 
> I was just trying to follow the pattern in ns-win.el, there are a number of
> requires at the beginning, after a comment saying ";; Documentation-purposes
> only: actually loaded in loadup.el."
> 
> I can easily drop the line, if you think it's better.

I see other files do the same, so I'm probably missing something
here.  Let's leave that as you wrote it.

> > 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, on behalf of one peculiar filesystem. Unless
> > there's some clever idea that avoids decoding each file name returned
> > by readdir, that is.
> 
> The eternal question of correctness versus speed...

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

> My gut feeling is that the time it takes to decode the file names is dwarfed by
> the time it takes to read the file list from the harddisk (this needs to be
> verified, of course).

I think you should time this.  My gut feeling is the other way around,
for several reasons:

  . reading file entries in a directory is essentially a system call,
    that is usually highly optimized code

  . modern OSes cache this stuff, so you can do that without ever
    hitting the disk

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

  . 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

Nevertheless, my gut feeling could also be false.  We should time
that.

> In addition, for systems like Linux, encoding and decoding are
> no-ops (as both the source and destination is UTF-8), so there won't
> be a penalty there.

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 agree that this is not a project for Emacs 25.1 -- however, I think that we
> should at explore this for future versions. I suggest that we push the current
> patch (after dropping the `require' line), close the current issue, and post a
> new bug report suggesting performing the completion on decoded strings.

I have a simpler idea for fixing the issue without decoding every file
in a directory.  Please wait for a couple of days.

(There's no need for another bug report, we could continue solving the
left-over problem as part of this one.)

Previous Next

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