[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: package.el encoding problem

From: Stefan Monnier
Subject: Re: package.el encoding problem
Date: Sat, 25 May 2019 11:26:21 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]