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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: thievol <at> posteo.net, handa <at> gnu.org, schwab <at> linux-m68k.org, 44486 <at> debbugs.gnu.org
Subject: bug#44486: 27.1; C-@ chars corrupt elisp buffer
Date: Mon, 09 Nov 2020 18:14:07 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Kenichi Handa <handa <at> gnu.org>,  thievol <at> posteo.net,
>   schwab <at> linux-m68k.org,  44486 <at> debbugs.gnu.org
> Date: Mon, 09 Nov 2020 16:44:00 +0100
> 
> > -  :prefer-utf-8 t)
> > +  :prefer-utf-8 t
> > +  :inhibit-null-byte-detection 0
> > +  :inhibit-iso-escape-detection 0)
> 
> Makes sense to me, but is there any particular reason to use 0 instead
> of t here?

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.

(We could use any non-nil, non-t value, of course; I've chosen to use
zero for consistency with what we do for 'undecided', see coding.c.)

Previous Next

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