GNU bug report logs - #44486
27.1; C-@ chars corrupt elisp buffer

Previous Next

Full log

Message #49 received at 44486 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: thievol <at> posteo.net, handa <at> gnu.org, larsi <at> gnus.org, schwab <at> linux-m68k.org,
 44486 <at> debbugs.gnu.org
Subject: Re: bug#44486: 27.1; C-@ chars corrupt elisp buffer
Date: Sat, 14 Nov 2020 17:09:20 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,  thievol <at> posteo.net,  handa <at> gnu.org,
>   schwab <at> linux-m68k.org,  44486 <at> debbugs.gnu.org
> Date: Sat, 14 Nov 2020 09:02:16 -0500
> 
> > 0 is different: it says to obey the value of
> > inhibit-null-byte-detection resp. inhibit-iso-escape-detection.  t
> > means inhibit the detection unconditionally, which is not what we
> > want.
> 
> Actually, for prefer-utf-8 files, I think we never want to automatically
> fallback to binary.

I think you are assuming prefer-utf-8 is something other than what it
is.  It is not a variant of UTF-8, it is a variant of 'undecided'
(i.e. it starts by detecting the encoding), which prefers UTF-8 if
that can decode the text.  inhibit-null-byte-detection etc. are
relevant to the detection phase, not to the decoding phase.  It is
wrong IMO to decide to use UTF-8 for a binary byte stream just because
it includes valid UTF-8 byte sequences.  If the input text is known to
be UTF-8, even though it includes null bytes, the user or the
application should either bind coding-system-for-read or
inhibit-null-byte-detection.

> IOW I think Thierry's situation shows a bug in Emacs rather than
> a pilot error.

I disagree.

Previous Next

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