Re: command line parsing on windows and the right encoding

[Eli Zaretskii]

> From: Andrés Ramírez <rrandresf@gmail.com>
> Date: Sat, 19 Feb 2022 17:40:55 +0000
> 
> Hi.
> 
> Reading this blogpost.
> ,---- [ https://nullprogram.com/blog/2022/02/18/ ]
> | The aged Emacs implementation is written in C rather than Lisp, steeped in 
> history with
> |  vestigial wrong turns. Emacs still only calls the “narrow” CreateProcessA 
> despite having
> |  every affordance to do otherwise, and uses the wrong encoding at that. A 
> personal source of
> |  headaches.
> `----
> 
> There is a couple of doubts:
> 1. Should emacs replace CreateProcessA with CreateProcessW?

We can't usefully do that, because (almost) all programs we invoke as
sub-processes don't use "wide" (a.k.a. "Unicode") APIs to access their
command-line arguments, so even if we used CreateProcessW, Windows
would convert the UTF-16 encoded arguments to the locale's
environment, and ruin what we did.

Using CreateProcessA at least lets us signal an error when the
command-line arguments cannot be encoded in the locale's encoding.

> 2. How Could the emacs-windows port have the right encoding when parsing
> command line arguments?

We already do.  We use the locale's preferred encoding by default, and
let Lisp programs override that by binding coding-system-for-write.