GNU bug report logs - #15803
default-file-name-coding-system: utf-8 better than latin-1 these days?

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 15803 <at> debbugs.gnu.org
Subject: bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?
Date: Fri, 11 Sep 2020 14:33:08 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> So if you found that the problem reveals itself in set-file-modes,
> let's see what happens there.  The relevant code is this:

Yeah, I don't think that function is the problem in itself, but I don't
know where the problem originates either.

>> foo: "\"/home/larsi/src/emacs/f\\363o/test/lisp/eshell/eshell-tests.elc\""
>> 
>> which seems to be correct,
>
> Where does the "foo:" printout comes from?  I wouldn't expect to see
> Latin-1 encoded strings inside Emacs, not normally anyway.

I just added a bunch of

          (message "foo: %S" variable)

here and there in byte-compile-file to watch how the passed-in string is
transformed. 

>> 		       (tempfile
>> 			(make-temp-file (expand-file-name target-file)))
>> 
>> is
>> 
>> "#(\"/home/larsi/src/emacs/fóo/test/lisp/eshell/eshell-tests.elcnjDFYY\" 0 65 (charset iso-8859-1))"
>
> I see nothing wrong here: this is how decoding works in Emacs.  And
> again, how did you produce this string?  As I explained above, the
> details of how you display these strings matter in this case.

Same way as above.

The file name is on the "f\\363o/test" form until make-temp-name, and
then it turns into a different string with a text property.  But I don't
know how much this is an artefact of how Emacs prints these things and
how much it's actually, er...  actual.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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