[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15803: default-file-name-coding-system: utf-8 better than latin-1 th
From: |
Lars Ingebrigtsen |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Eli Zaretskii <eliz@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
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/09
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/09
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/10
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/10
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?,
Lars Ingebrigtsen <=
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Michael Albinus, 2020/09/12
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/12
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Lars Ingebrigtsen, 2020/09/11
- bug#15803: default-file-name-coding-system: utf-8 better than latin-1 these days?, Eli Zaretskii, 2020/09/11