Re: master 28bf387: Tweak Fdirectory_append for efficiency

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Jul 2021 08:38:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You should indeed be able to do that, that's my case #2.  The case
> > that doesn't have to work and doesn't make sense is this
> >
> >   (multibyte-string-p (encode-coding-string "bár" 'latin-1))
> >   => nil
> >
> >   (multibyte-string-p "/tmp/bár")
> >   => t
> >
> >   (directory-append "/tmp/bár" (encode-coding-string "bár" 'latin-1))
> >   => "/tmp/b\303\241r/b\341r"
> 
> The function isn't really concerned with charsets -- that's an
> orthogonal issue.

I wasn't talking about charsets.  I used encode-coding-string just to
make sure the string is unibyte and emulates the file names we get
from the filesystem before file-coding-system and friends is set up
during startup.

IOW, what you see above is what will happen when the function gets
passed COMPONENTS some of which are multibyte, and some unibyte but
non-ASCII.  I'm saying that such a situation makes no sense, and
perhaps should be even flagged as an error, because it probably means
one of the COMPONENTS wasn't decoded correctly.  If you can describe a
situation where this is legitimate, please do.

> The user may well have a unibyte string that contains non-ASCII octets
> (note -- not characters), and I see no reason why a string concatenating
> function should refuse to handle those.  It's up to the caller.

I tried to explain that above.  If you are still unconvinced, so be
it.