Subject: Fwd: [email-masked]

From: Sean Whitton <[email-masked]>
Date: Wed, 05 Mar 2025 20:13:59 +0800

Forwarding with permission.

Eli, this is a Windows thing, do you think there is something to
investigate and fix here, or perhaps this is already captured somewhere
else?

We should probably close this specific bug, but I wanted to check with
you.

Thanks.

-- 
Sean Whitton

-------------------- Start of forwarded message --------------------
From: Rui Duan <[email-masked]>
Date: Tue, 4 Mar 2025 10:09:51 -0500
Message-ID: <[email-masked]>
Subject: Re: [email-masked]
To: Sean Whitton <[email-masked]>

Hi Sean,

Thank you for asking! I guess the bug still exists. But you can close this
bug if there are not many people complaining about this issue.

I don't have the GBK Chinese Windows at hand, so I cannot test all the 3
example cases.

I've just tested my example 3 (`cd` a Chinese directory) in a Shell mode
buffer on an English (latin) Windows system with GNU Emacs 29.4. Emacs
passed whitespaces (0x0A) to the Windows command line, instead of UTF-8
encoded string. Emacs detected that the process encoding system is latin,
it cannot convert the UTF-8 encoded Chinese characters to the latin
encoding, then it passes whitespaces as placeholders to the shell process.
This behaviour is different from what I saw 15 years ago.

However, I don't think this is the right logic to handle the encoding
conversion problem. The correct logic should be: try to get the OS encoding
system, if it succeeds, try to encode the string using that encoding system
and pass the encoded string to the subprocess, if failed, report error.
However, the current behaviour is to use whitespaces as placeholders.

Best Regards,
Rui (Ryan) Duan

On Mon, Mar 3, 2025 at 11:14 PM Sean Whitton <[email-masked]>
wrote:

> Hello Ryan Duan,
>
> Can you still reproduce <https://debbugs.gnu.org/3616> ?
>
> If not, I would propose we close this very old bug report.
>
> --
> Sean Whitton
>
-------------------- End of forwarded message --------------------