GNU bug report logs - #50560
28.0.50; 'insert-file-contents-literally' on multibyte buffers

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 50560 <at> debbugs.gnu.org
Subject: bug#50560: 28.0.50; 'insert-file-contents-literally' on multibyte buffers
Date: Mon, 13 Sep 2021 10:19:26 +0200

Augusto Stoffel <arstoffel <at> gmail.com> writes:

>> `insert-file-contents-literally' does insert "literally" -- but the byte
>> contents of the internal buffer structure can't be violated (emacs uses
>> utf-8 (plus extensions) for multibyte buffers).
>
> Ah, sure, there is no coding _conversion_, but the bytes are still
> interpreted according to the buffer's coding system.

No, quite the opposite -- `insert-file-contents-literally' inserts the
octets from the file in a way that makes them not be interpreted as
characters:  You end up with a buffer where each point in the buffer has
something that represents one octet.  (In reality, there's usually more
than one byte "in the background", since it takes several bytes to
represent an octet like #x90 in a multibyte buffer.)

> I guess that's obvious in hindsight.  Still, reading the bytes from a
> file is slightly trickier than it might seem, so there could be a word
> of caution somewhere.

I think this is all covered in the lispref manual.  It's a very
complicated and confusing subject, and I don't think this docstring is
the place to get into it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.