[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:39:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Another confusing data point. If I say "make" in the test directory, I
get:
foo 1: "\"/home/larsi/src/emacs/f\\363o/test/lisp/eshell/eshell-tests.elc\""
foo 2: "#(\"/home/larsi/src/emacs/fóo/test/lisp/eshell/eshell-tests.elcGvbK3T\"
0 65 (charset iso-8859-1))"
If I just say "make" in the main directory, I get this:
foo 1: "\"/home/larsi/src/emacs/f�o/lisp/dos-w32.elc\""
foo 2: "\"/home/larsi/src/emacs/fóo/lisp/dos-w32.elcXgukAl\""
Or, if that doesn't survive emailing, here's an umage:
Note -- no text properties, and not represented as "f\363o".
*scratches head*
So is this a problem with how ert calls the byte compiler after all?
This is with
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 966990bac9..07448033ac 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1990,6 +1990,7 @@ byte-compile-file
(with-current-buffer output-buffer
(goto-char (point-max))
(insert "\n") ; aaah, unix.
+ (message "foo 1: %S" (prin1-to-string (expand-file-name
target-file)))
(if (file-writable-p target-file)
;; We must disable any code conversion here.
(progn
@@ -2007,6 +2008,7 @@ byte-compile-file
(cons (lambda () (ignore-errors
(delete-file tempfile)))
kill-emacs-hook)))
+ (message "foo 2: %S" (prin1-to-string tempfile))
(unless (= temp-modes desired-modes)
(set-file-modes tempfile desired-modes 'nofollow))
(write-region (point-min) (point-max) tempfile nil 1)
--
(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?, (continued)
- 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, 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 <=
- 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?, Stefan Kangas, 2020/09/09