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: Wed, 16 Dec 2015 00:05:40 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:
> I certainly see a pre-write-conversion function in ucs-normalize.el:
> ucs-normalize-hfs-nfd-pre-write-conversion which calls
> ucs-normalize-HFS-NFD-region.  So I'm not sure I understand what you
> are saying.

I was talking about the "utf-8-nfd" encoding in ns-win.el. I'd
missed the statement that the problem had been reproduced with
utf-8-hfs.

I can't actually reproduce the problem myself with utf-8-hfs.  I
thought I had it once, but only immediately after switching from
utf-8-nfd (maybe the bad completion result from utf-8-nfd was in
some kind of cache?), and now I can't even reproduce that.
Otherwise, it seems to fix the problem.  Anders, can you try
this again from a clean emacs -Q session, and in particular load
ucs-normalize and set the coding system to utf-8-hfs _before_
attempting any completion?

--

Incidentally, I do get one other bit of bizarre behavior
associated with this.  If I have multiple files that start with
the same base letter and different (or no) accents, pressing TAB
_deletes_ that letter.  E.g. files: à1 á2 a3.  C-x C-f a TAB,
deletes the "a". I'd expect it to either offer all three
filenames, or just a3.

Why exactly does completion do matching with encoded prefix
against raw filenames, rather than with unicode prefix against
decoded filenames, anyway?

Previous Next

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