From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#52816: 28.0.90; misspelling of windows-nt system-type in reset-language-environment, enquiring about default-process-coding-systems on MS-Windows Date: Mon, 27 Dec 2021 19:26:17 +0200 Message-ID: <83k0fqm01y.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31602"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rgm@gnu.org, 52816-done@debbugs.gnu.org To: Ioannis Kappas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 27 18:27:21 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n1tmK-000814-LO for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Dec 2021 18:27:20 +0100 Original-Received: from localhost ([::1]:50220 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n1tmI-0000OO-H5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Dec 2021 12:27:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1tm2-0000NI-Oz for bug-gnu-emacs@gnu.org; Mon, 27 Dec 2021 12:27:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60875) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n1tm2-00057s-Fq for bug-gnu-emacs@gnu.org; Mon, 27 Dec 2021 12:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n1tm2-0002Gg-8m for bug-gnu-emacs@gnu.org; Mon, 27 Dec 2021 12:27:02 -0500 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Dec 2021 17:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 52816 X-GNU-PR-Package: emacs Mail-Followup-To: 52816@debbugs.gnu.org, eliz@gnu.org, ioannis.kappas@gmail.com Original-Received: via spool by 52816-done@debbugs.gnu.org id=D52816.16406259888657 (code D ref 52816); Mon, 27 Dec 2021 17:27:02 +0000 Original-Received: (at 52816-done) by debbugs.gnu.org; 27 Dec 2021 17:26:28 +0000 Original-Received: from localhost ([127.0.0.1]:44187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n1tlT-0002FZ-VO for submit@debbugs.gnu.org; Mon, 27 Dec 2021 12:26:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n1tlS-0002FK-PS for 52816-done@debbugs.gnu.org; Mon, 27 Dec 2021 12:26:27 -0500 Original-Received: from [2001:470:142:3::e] (port=33986 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1tlN-0004wR-IX; Mon, 27 Dec 2021 12:26:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1smWBouaXR9dRSmpHfDX9O4DOZ2aezHGdKJAr6UzuuM=; b=WvQPiM2kAh7A BrNfefpszQ4yVMunbRInDsi++n1yu+zrSyAieufVfnMfNkXfkaqRPk5ILjd0BP9V26UNIpUBiNM67 q4Ne3l9oCiIeV893NH0jUMotCz+2NtpxMZF2XxmEzY/Qd0tHEyHsJrGMkOESgUP/Ux5HYs3Aoj/oy SI8FJE6UrK5weMbgLnrUaqsBw5OoPGSTDMUgHSgJeqU0LwlYO613Xd3SqUEMcXC8bprZzowvy4zKS +51rtcTQqV6Zw7xr2+oPxvX7+HQ4r1HPkN+ZC0NKv3xK2XWN7KmJCompYmAFP15FUM/U6PGQnNra2 44DBvYU1vSOJwdt8VS5+Aw==; Original-Received: from [87.69.77.57] (port=4123 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1tlN-00019J-DH; Mon, 27 Dec 2021 12:26:21 -0500 In-Reply-To: (message from Ioannis Kappas on Mon, 27 Dec 2021 10:52:20 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:223203 Archived-At: > From: Ioannis Kappas > 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.