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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Wed, 03 Jan 2018 15:09:06 -0500
> 
> > Eight-bit-* characters are not in general modified by encoding them,
> > so you could encode them any number of times and still get the same
> > bytes as result.
> 
> Agreed.  But even if it were not the case, I don't see why that would
> explain the presence of this code.

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

> >> > As for the reason for using string-to-multibyte: maybe it's because we
> >> > use concat further down in the function, which will determine whether
> >> > the result will be unibyte or multibyte according to its own ideas of
> >> > what's TRT?
> >> But `concat` will do a string-to-multibyte for us, if needed
> > Not if the other concatenated parts are ASCII (which tend to be
> > unibyte strings).
> 
> But that's still perfectly fine as well since it will then result in
> a unibyte string which will get "encoded" correctly.

Where do you see encoding in this picture?

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.