Re: package.el encoding problem

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 25 May 2019 11:26:21 -0400
> 
> > 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.

Yes.  In fact, binding buffer-file-coding-system is not useful at all.

So why not bind coding-system-for-write here?

> > 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.

We disagree here.  We can put bytes into a multibyte buffer, they have
a special representation there which tells they are raw bytes, so
there's nothing wrong with doing that.

> > 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.

Using a multibyte buffer removes one subtlety from what we should
educate people to do in this case, so it's easier to get that right.

> 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.

Sorry, I see no trouble here.  the only trouble is the binding of
buffer-file-coding-system instead of coding-system-for-write.