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 #89 received at 22169 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 09:38:08 +0100

[Message part 1 (text/plain, inline)]

>
> > Below is a patch where I have dropped the old encoder and use the new
> instead.
> > The only thing noteworthy is that `ucs-normalize' is loaded by loadup
> (when ns
> > is used) and thus included in the dumped Emacs (if I understand
> correctly).
> > Unless anybody objects, I'll push it in a couple of days.
>
> Looks good to me, with one comment:
>
> > diff --git a/lisp/loadup.el b/lisp/loadup.el
> > index f0caa8b..dda433e 100644
> > --- a/lisp/loadup.el
> > +++ b/lisp/loadup.el
> > @@ -276,6 +276,7 @@
> >  (if (featurep 'ns)
> >      (progn
> >        (load "term/common-win")
> > +      (load "international/ucs-normalize")
> >        (load "term/ns-win")))
> >  (if (fboundp 'x-create-frame)
> >      ;; Do it after loading term/foo-win.el since the value of the
> > diff --git a/lisp/term/ns-win.el b/lisp/term/ns-win.el
> > index 0b3e3bd..9bd59fc 100644
> > --- a/lisp/term/ns-win.el
> > +++ b/lisp/term/ns-win.el
> > @@ -51,6 +51,7 @@
> >  (require 'menu-bar)
> >  (require 'fontset)
> >  (require 'dnd)
> > +(require 'ucs-normalize)
>
> Why do you need the 'require' if loadup will unconditionally load
> ucs-normalize?
>

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.


> > After giving this some thought, it feels like the file name matching
should be
> > done on decoded strings (so that an "a" doesn't match the "a" in a
decomposed
> > "å"). However, this is a major change and needs to be discussed further.
>
> 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...

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). 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.

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.

    -- Anders

[Message part 2 (text/html, inline)]

Previous Next

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