bug#52816: 28.0.90; misspelling of windows-nt system-type in reset-language-environment, enquiring about default-process-coding-systems on MS-Windows

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Mon, 27 Dec 2021 10:52:20 +0000
> Cc: rgm@gnu.org
> 
> there appears to have been a symbol spelling mistake in a recent
> commit a4bfb0bc5c14e002c0926fc320aeb4a3fc261447 to "Default Emacs to
> UTF-8 instead of Latin-1". The `window-nt' symbol is used instead of
> `windows-nt' when checking for membership in `system-type`.

Thanks, fixed.

> It does not appear to be of much consequence though, since both
> `default-file-name-coding-system' and `default-process-coding-system`
> affected by it appear to be overwritten later on anyway at runtime.

Yes, because fortunately those typos are in
reset-language-environment, which is immediately followed by the likes
of set-language-environment.  IOW, those are defaults that are never
seen in real usage.

> I think the expectation at this time and age is for communication
> between processes should be in Unicode by default, so as to allow
> multilingual sets to passed on between them.

We still cannot use UTF-8 by default for process I/O on MS-Windows, as
UTF-8 is still not a first-class citizen there.  Latest versions of
Windows support it better, but not as well as other (fixed-length)
encoding, and AFIK even that incomplete support needs that the user
turns on an optional feature that is meant for developers.

> `flycheck' is an example of a utility which is using `call-process' to
> marshal buffers to/from a checker sub-processes. Sending multilingual
> data to the checkers on MS-Windows are likely to cause failure due to
> the default proc encodings being `undecided-unix', and thus encoded as
> iso-8859-1 dropping the unicode chars. On GNU/Linux the same operation
> is most likely to succeed, because the default encoding is most likely
> to be set to `utf8-unix', courtesy of the LANG env variable being most
> likely set to a UTF-8 codepage such as `C.UTF-8', and picked up by the
> locale logic in Emacs.

If the checker sub-processes used with flycheck indeed support UTF-8
I/O (I sincerely doubt that, unless you are using Cygwin or MSYS
programs, not native MS-Windows programs), then your customizations of
flycheck should ensure it uses UTF-8 for communicating with those
programs.  We have process-coding-system-alist for that purpose.

> Also, should the eol type be set to -dos on the input encoding? The
> comment suggests that this was done because most programs back then
> were requiring unix eols, but I don't believe that this is the case
> any more.

What comes _from_ a subprocess on Windows can have DOS-style CRLF
EOLs, so using -dos in that case makes sure we decode the EOLs
correctly, and don't leave ^M characters in the text that ends up in
Emacs buffers.  What goes _to_ a subprocess can have Unix EOLs
because MS-Windows programs don't mind if they get LF without a CR.

> A final note, the documentation under `Default Coding Systems` gives a
> warning that `undecided' coding systems do not work reliably with
> asynchronous sub-process output, perhaps this is an additional
> argument while we should move away from the undecided default above?

No, because the problems with UTF-8 on Windows are worse.

I'm closing this bug, as the problem you reported is now fixed on the
emacs-28 branch.