From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: package.el encoding problem Date: Sat, 25 May 2019 11:26:21 -0400 Message-ID: References: <87blztw65c.fsf@wavexx.thregr.org> <83k1ef3ugs.fsf@gnu.org> <83ef4m4pet.fsf@gnu.org> <837eae4lw0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="209444"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 25 17:29:28 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hUYbw-000sJU-IS for ged-emacs-devel@m.gmane.org; Sat, 25 May 2019 17:29:28 +0200 Original-Received: from localhost ([127.0.0.1]:43364 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUYbv-0006Ud-DD for ged-emacs-devel@m.gmane.org; Sat, 25 May 2019 11:29:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUYbp-0006Tn-0d for emacs-devel@gnu.org; Sat, 25 May 2019 11:29:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUYZ5-0003eG-5F for emacs-devel@gnu.org; Sat, 25 May 2019 11:26:33 -0400 Original-Received: from [195.159.176.226] (port=48634 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hUYZ4-0003dl-Ux for emacs-devel@gnu.org; Sat, 25 May 2019 11:26:31 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hUYZ3-000p3f-H4 for emacs-devel@gnu.org; Sat, 25 May 2019 17:26:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:Ya4cXVmIc5Pm6MT7vwMIQktlJKc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236982 Archived-At: > You previously said that in the past we attempted to bind > coding-system-for-write, which in general is the easiest way of > preventing the prompt. Didn't it work? For some reason this function does something else: (defun package--write-file-no-coding (file-name) (let ((buffer-file-coding-system 'no-conversion)) (write-region (point-min) (point-max) file-name nil 'silent))) AFAIK using coding-system-for-write would have solve the problem as well. > One obvious benefit is that you won't need to set the buffer to be > unibyte. (set-buffer-multibyte nil) sets up the buffer to receive bytes. Since we're putting bytes into the buffer, it's The Right Thing to do. > People tend to regard this as some kind of black magic, which creates > myths, like the (wrong) idea that unibyte text cannot be processed > correctly in a multibyte buffer. I think they're right: it's hard to get it right. Partly because it encourages confusion between bytes and chars (and confusion between sequences of bytes and sequences of chars). Don't get me wrong: it's important that it be possible to do it, because that's sometimes necessary. But when the code only manipulates bytes, using any multibyte objects along the way is asking for trouble. > I'd rather we avoided substantiating such myths. And I'd rather we clarify that chars aren't bytes and vice versa. [ I also wish we could through away the "unibyte" and "multibyte" vocabulary which again encourages such confusion. ] > Also, we should in theory be able to eliminate unibyte buffers, at > least in Lisp application code. I think this will help create more confusion. Stefan