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

Previous Next

Full log

Message #76 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, 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: Sun, 15 Nov 2020 17:14:05 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: thievol <at> posteo.net,  larsi <at> gnus.org,  schwab <at> linux-m68k.org,
>   44486 <at> debbugs.gnu.org
> Date: Sat, 14 Nov 2020 17:56:36 -0500
> 
> >> For .el files, we can always bind inhibit-null-byte-detection to t
> >> when we load or visit such files.
> > Alternatively, we could introduce a separate coding-system whose
> > :inhibit-null-byte-detection property is t, and use that for *.el
> > files.
> 
> If you want to go that route, that's fine by me.

I actually think that we don't need to do anything.  We've lived for 7
years with a reality that is worse than what is now on master, and no
one complained.

But if you are very unhappy about this, we _could_ introduce a new
coding-system for *.el files.

> (especially since we don't have any evidence that potential other
> users would favor the current behavior over the
> inhibit-null-byte-detection one).

The current behavior on master is to heed inhibit-null-byte-detection;
the current behavior in Emacs 27 is to ignore it, and always consider
a .el file with null bytes as binary.  I hope you agree that the
behavior on master is slightly better, at least in that it won't
surprise users.

Previous Next

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