Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: Eli Zaretskii , 48029@debbugs.gnu.org, >> jakanakaevangeli@chiru.no >> Date: Thu, 07 Jul 2022 20:51:48 +0000 >> >> We have the symbol `nonascii-test-žžž' correct into our pipeline. >> >> Then we prepare the file that will be executed by the subprocess that >> will do the actual compilation, we do this in `comp-final'. >> >> Here when we print `nonascii-test-žžž' using `prin1-to-string' this >> becomes "nonascii-test-\x017e\x017e\x017e" (exploring it with the >> debugger). >> >> This is then stored in the temp file I mentioned, the file has on top >> ";; -*-coding: nil; -*- " and the symbol is shown as >> "nonascii-test-\305\276\305\276\305\276" if I visit it on my emacs. >> >> Now two options, either we are not printing it as we should or either >> the reader doesn't know he has to handle these non ascii characters >> while reading back. >> >> I'm no expert in this area, I guess will be evident to experts what we >> are not doing correctly here. > > 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. > 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. Should this patch go in master or into the release branch? Regards Andrea