Re: File name completion with non-ascii filenames

[Eli Zaretskii]

On Sun, 13 Jan 2002, Richard Stallman wrote:

> There are several places in file_name_completion that currently deal
> with coding systems.  For instance, the part that checks
> completion-ignored-extensions, and the part that checks
> Vcompletion_regexp_list, and the part that compares various
> possible completions.

Yes, they all need to be changed in the same way.  But for this little 
experiment, I don't think it matters, since the default values of these 
variables are either nil or pure-ASCII.

> Once you have decoded the file name from the directory, it would be
> better to save that and use it in all the rest of the code.

Yes.

> The part that checks Vcompletion_regexp_list seems to have a bug
> because it checks the regexps against the raw (not decoded) file name
> data.

That part uses Fstring_match to compare, and I thought Fstring_match does 
TRT with both unibyte and multibyte strings.  Doesn't it?

Anyway, if the directory entry is already decoded, this is a moot point, 
as we should use the decoded string.

Should I understand that you don't see the slow-down I measured as 
significant, and I can go ahead with making these changes?

There's one more complication with decoding directory entries returned by 
readdir: if the partial file name against which we are matching the 
directory entries uses mule-unicode-* characters, but 
file-name-coding-system decodes the directory entries into some other 
charset, like latin-2, we will fail to match when the original code would 
succeed.  But I think if we only use the decoded entries under 
case-insensitive completion, we could at least do as well as the current 
code.