Re: Why does dired go through extra efforts to avoid unibyte names

[Stefan Monnier]

> I meant to ask why do _you_ worry about eight-bit-* characters being
> encoded more than once?

I don't really worry about it (other than as part of understanding why
the only explanation accompanying this code mentions it).

> I think the issue is that we want dired-get-filename to always return
> a multibyte string, so that its callers don't need to deal with the
> complications, like inserting unibyte strings into multibyte buffers,
> concatenating them with leading directories to form other file names,
> etc.

AFAICT a multibyte string which only consists of ascii and eight-bit
bytes will "suffer" from the exact same problems as the corresponding
unibyte string (two such strings can be called "equal modulo
multibyteness").

Actually, most primitives will handle those two strings in the same way
E.g. inserting either string into a buffer gives the same result (both
for unibyte and multibyte buffers), concatenating either of those
strings to a multibyte string gives the same result.
Concatenating either of those strings to a unibyte string does not give
the same result, but the two results are again "equal modulo
multibyteness".

So I can't imagine a scenario where calling string-to-multibyte here
will help subsequent code.


        Stefan