bug#48902: 28.0.50; Directory names containing apostrophes and backticks cause problems

[naofumi]

On Tuesday, June 08, 2021 20:18 CEST, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Mattias Engdegård <mattiase@acm.org>
> > Date: Tue, 8 Jun 2021 19:45:22 +0200
> > Cc: 48902@debbugs.gnu.org, Alan Third <alan@idiocy.org>,
> >  Rudolf Adamkovič <salutis@me.com>, naofumi@yasufuku.dev
> >
> > The quick fix of reverting to stringWithUTF8String: will work, but the real 
> > problem is that we have no control of the encodedness of lisp strings being 
> > passed around.
>
> The usual technique in these cases is to keep Lisp strings unencoded,
> encode them when passing to the low-level C functions, and pass to
> those functions only the pointer to the string's data.
>
> In those rare cases when you really need to pass a Lisp string that is
> an encoded file name, call the argument "encoded_file" or somesuch.
> But these cases should be rare exceptions.
>
>

I agree that [NSString stringWithLispString:] is working as expected,
and it is not the real problem.

For example, another patch using STRING_SET_MULTIBYTE() is here.
This looks still just a quick fix and bit weired, though..

attachments:
0001-Fix-to-show-images-with-non-ascii-filename-STRING_SET_MULTIBYTE.patch
image-non-ascii-filename-STRING_SET_MULTIBYTE-macos.png
image-non-ascii-filename-STRING_SET_MULTIBYTE-linux.png

On the other hand, I cannot find out that non-UTF-8 filename coding is
really needed on macOS.  It might be over-engineered thing, and just an 
overhead.

Regards,
--Naofumi

0001-Fix-to-show-images-with-non-ascii-filename-STRING_SET_MULTIBYTE.patch
Description: Binary data