From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#48137: 27.2; `package-install-file' fails when loading a package file with DOS line endings Date: Mon, 03 May 2021 14:23:53 -0400 Message-ID: References: <834kfmabvs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37233"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 48137@debbugs.gnu.org To: Ioannis Kappas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 03 20:25:58 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 1lddGX-0009VE-Vp for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 May 2021 20:25:58 +0200 Original-Received: from localhost ([::1]:40066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lddGX-0001YQ-2t for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 May 2021 14:25:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37218) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lddFe-0000va-98 for bug-gnu-emacs@gnu.org; Mon, 03 May 2021 14:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36456) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lddFd-0001ln-QI for bug-gnu-emacs@gnu.org; Mon, 03 May 2021 14:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lddFd-0003l8-Mx for bug-gnu-emacs@gnu.org; Mon, 03 May 2021 14:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 May 2021 18:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48137 X-GNU-PR-Package: emacs Original-Received: via spool by 48137-submit@debbugs.gnu.org id=B48137.162006625714439 (code B ref 48137); Mon, 03 May 2021 18:25:01 +0000 Original-Received: (at 48137) by debbugs.gnu.org; 3 May 2021 18:24:17 +0000 Original-Received: from localhost ([127.0.0.1]:48000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lddEv-0003kp-A0 for submit@debbugs.gnu.org; Mon, 03 May 2021 14:24:17 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lddEf-0003kR-FG for 48137@debbugs.gnu.org; Mon, 03 May 2021 14:24:16 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 26EAA809E6; Mon, 3 May 2021 14:23:56 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7EC7580194; Mon, 3 May 2021 14:23:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1620066234; bh=7oAX1VrDOsVrif9T/5yfcmfyGTDRZiNO+KMPrBjbNlU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=n3E+Xa4cwz8RnfcfjWt1DgLOi7YIk1ah8uXPA/Ql4vOD8WNCX//N+8jFTfUq65tSk 7tQvzL4gLBU+EdB2ZIy7qARPMIEIQxb+/huDzSxXK1EpmGH18ZH7IRUL+DtPTrBYAr nwnIeFH/fEDX6vlrXvcjQaiV8AxkdYXAZjjr27V1RFrTlw3WTFQhP7vXT6HeCkaRRF gTSaMFVIXgNiTcHhT+aIhYxfJp2Y4U3/ck8F8ylwpfkg8RMsH6RES2ltAHgMIv0BzF jaz/raW0JgL0QYedcUFZzQwI57L6cY9KHIkHqbwq+SBay7NfsBqd+3E0MkVvF/5mDI 9xTYnb8AqqDIg== Original-Received: from alfajor (unknown [108.161.125.61]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3D1DE1201B5; Mon, 3 May 2021 14:23:54 -0400 (EDT) In-Reply-To: (Ioannis Kappas's message of "Mon, 3 May 2021 18:47:34 +0100") 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:205553 Archived-At: Ioannis Kappas [2021-05-03 18:47:34] wrote: > On Sat, May 1, 2021 at 2:51 PM Stefan Monnier wrote: >> > I don't think this is TRT, because insert-file-contents also decodes >> > the character encoding, not just the EOL encoding. >> >> I think for `.el` files it's actually correct to decode the character >> encoding here (it's maybe not necessary, but I think it's at least >> as correct as what we do now, since `package-install-from-buffer` >> expects a "normal" buffer, hence for `.el` buffers it expects one where >> characters have been decoded). > Thanks Stefan. Does this also apply to the only other use of > `insert-file-contents-literally' in 'package,? I don't think so, no. > In particular `package--with-response-buffer-1' is referenced by > `package-check-signature' This definitely needs to deal with bytes only, we don't want any encoding/decoding to risk changing the byte contents. > and `package--download-one-archive'. I think the same is true here. > (I am personally more in favor of supporting DOS files, because it > makes the caller's life easier on MS-Windows and brings them on par > with Unix, though Eli's concern has to be addressed first) My own opinion is that .el files are files that belong to Emacs and they should use Emacs's "native" file format, whatever that is. I think the "most native" would be `utf-8-emacs-unix` so I'd be OK with deprecating all other encodings, but I don't think that's going to happen ;-) My comment on that subject was instead focused on files distributed via ELPA (and hence wouldn't really apply to `package-install-file`): we could document that those files should use utf-8 and unix EOLs. At the same time, I haven't seen a clear technical benefit to imposing such a constraint, so it's probably not worth the trouble. [ There can be a real technical advantage to imposing `utf-8-emacs-unix` for .el files since it can save us the trip through `load-with-code-conversion` which slows down `load`ing non-byte-compiled files, but that doesn't matter much for ELPA files since those are usually byte-compiled anyway. ] Stefan