GNU bug report logs - #75207
29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8

Previous Next

Full log

Message #8 received at 75207 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: michal <at> 0lock.xyz
Cc: 75207 <at> debbugs.gnu.org
Subject: Re: bug#75207: 29.4;
 Path conversion from native codepage to UTF-8 fails when Windows is
 set by default to UTF-8
Date: Mon, 30 Dec 2024 21:13:07 +0200

severity 75207 wishlist
thanks

> Date: Mon, 30 Dec 2024 12:12:02 +0000
> From: michal--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Emacs generates gibberish UTF-8 characters during conversion from native
> codepage to UTF-8 if experimental default UTF-8 codepage is set on
> Windows.

Please provide the minimum recipe for reproducing this, starting from
"emacs -Q".  What exactly did you convert, and how?  And what problems
did you see, exactly?  Also, what do the following commands produce
inside "emacs -Q"?

  M-: (getenv "ENU") RET
  M-: current-locale-environment RET
  M-: w32-ansi-code-page RET
  M-: (default-value 'buffer-file-coding-system) RET

In general, the UTF-8 codepage on Windows is not (yet) supported.  In
particular, some functions we use in Emacs assume the system codepage
cannot be a multibyte encoding.  Also, invoking subprocesses on
Windows doesn't currently support anything but single-byte encoding of
the program's name and its command-line arguments, for boring
technical reasons.  For that reason, I don't recommend using the UTF-8
codepage, and I don't recommend making UTF-8 the default encoding on
MS-Windows.

That said, presenting a clear recipe could help us gradually improve
support for this, as Windows improves its part in parallel.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.