unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: package.el encoding problem
Date: Sat, 25 May 2019 11:26:21 -0400	[thread overview]
Message-ID: <jwv8suutvbe.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: 837eae4lw0.fsf@gnu.org

> 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




  reply	other threads:[~2019-05-25 15:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 15:18 package.el encoding problem Yuri D'Elia
2019-05-23 15:27 ` Noam Postavsky
2019-05-23 15:33   ` Yuri D'Elia
2019-05-24 15:45 ` Stefan Monnier
2019-05-24 16:36   ` Stefan Monnier
2019-05-25  6:43     ` Eli Zaretskii
2019-05-25 12:15       ` Stefan Monnier
2019-05-25 13:47         ` Eli Zaretskii
2019-05-25 14:55           ` Stefan Monnier
2019-05-25 15:03             ` Eli Zaretskii
2019-05-25 15:26               ` Stefan Monnier [this message]
2019-05-25 16:03                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv8suutvbe.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).