Re: Multibyte and unibyte file names

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > But it was unnecessary in the first place in Emacs.
 > 
 > It _is_ necessary because file names passed to system APIs _must_ be
 > encoded.  That's where the bugs mentioned here (already fixed, btw)
 > happen: in the implementation of 'stat' we have in Emacs that does a
 > better job than the MS runtime, and in other similar cases.

Of course they need to be encoded file names.  The question is, were
they stored in encoded form, or were they encoded just before passing
them to the OS?  I'm recommending the latter strategy.

 > It's not premature.  directory-files-and-attributes, used on Windows
 > to emulate 'ls', must be fast enough even in large directories,
 > because otherwise Dired will be painfully slow to start.

But encoding and decoding can't add to those performance problems,
because Dired must do the decoding anyway to fill the buffer, and
encoding happens once and is very short.

 > It's not rocket science, true.  I'm just saying that if it isn't
 > required, it's best avoided.

Hey!  That's precisely my point about unibyte.

 > In any case, as long as file-name primitives support unibyte (encoded)
 > file names, there's nothing to prevent such examples from popping up.

True.  They *never* happen in XEmacs though.  They *can't*.  Functions
which manipulate text in XEmacs work on internal representation, never
in encoded form.  That's just too risky, and demands too many special
cases to be reliable.

But I guess you just don't have enough manpower to change this.