GNU bug report logs - #48029
28.1; [native-comp] Function names with non-ascii characters

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: larsi <at> gnus.org, 48029 <at> debbugs.gnu.org, jakanakaevangeli <at> chiru.no
Subject: bug#48029: 28.1; [native-comp] Function names with non-ascii characters
Date: Fri, 08 Jul 2022 15:40:35 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: larsi <at> gnus.org, 48029 <at> debbugs.gnu.org, jakanakaevangeli <at> chiru.no
> Date: Fri, 08 Jul 2022 08:49:42 +0000
> 
> > Why do we have ";; -*-coding: nil; -*- "?  I think that's the problem:
> > it should be ";; -*-coding: utf-8; -*- " instead.  Where does the nil
> > come from?
> 
> AFAIR at the time we encountered a situation when one of these files was
> read back with some other encoding (I guess it's heuristic?) so fixing
> the encoding to nil solved the issue.

You mean, bug#45433?  If the problem is EOL conversion, using
utf-8-unix instead of utf-8 should take care of that.  Or maybe even
use utf-8-emacs-unix.

Are we likely to write bytecode into this temporary file?

> > Lisp sources are by default UTF-8 encoded, so that should be the
> > default for the temp file we write.  Bonus points for using the actual
> > encoding of the Lisp source file there (which in very rare cases can
> > be something other than UTF-8).
> 
> Ok attached the patch that sets it to utf-8, seems to work for me.
> 
> I'll have a look on how to spill the original coding system and get the
> bonus points hopefully next week.

Thanks.

> Should this patch go in master or into the release branch?

To the release branch, if Lars agrees.  But let's first try to see if
bug#45433 is not back after the above change.

Previous Next

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