Re: Multibyte and unibyte file names

[Stefan Monnier]

> What I meant was to return decoded file names from all file-name
> primitives, such as file-name-nondirectory, even if their input was
> encoded.

It's probably OK to do that, but I wonder why we'd need to do it: under
what circumstances could such a primitive receive an encoded file-name,
if all the file names returned to Elisp (by things like directory-files)
are already decoded?

>> Which is why I suggest to decode right away in the functions that return
>> file names (e.g. directory-files).
> We already do that, so there's no issue in that department.

Good.

> The issue is in the file-name primitives that want to support both
> encoded and decoded file names, and as I understand from this
> discussion, this feature should stay.

Of course, we shouldn't just reject encoded filenames, but I don't see
why we should worry too much about them.

> So some things will never work with encoded file names, but I guess no
> one cares, because most of those problems go away if the encoding is
> UTF-8.  Fine; if no one cares, neither do I.

Actually, even with other coding systems, this shouldn't be a serious
issue since encoded file names should be rare.


        Stefan