bug#81606: Mojibake with UTF-8 file names

Eli Zaretskii <[email protected]>
Newsgroups gmane.emacs.bugs
Message-ID <[email protected]>
> From: Arash Esbati <[email protected]>
> Cc: [email protected],  [email protected]
> Date: Fri, 14 Aug 2026 11:54:09 +0200
> 
> Eli Zaretskii <[email protected]> writes:
> 
> > Edebug has a command to produce a backtrace; please use that.
> 
> Ah, thanks for the hint:
> 
> --8<---------------cut here---------------start------------->8---
> latexenc-find-file-coding-system((insert-file-contents "/path/to/ä-include.tex" t nil nil nil))
> insert-file-contents("~/path/to/ä-include.tex" t)
> find-file-noselect-1(#<buffer ä-include.tex> "~/path/to/ä-include.tex" nil nil "~/path/to/ä-include.tex" (125108739 16777233))
> find-file-noselect("~/path/to/ä-include.tex" nil nil t)
> find-file("~/path/to/ä-include.tex" t)
> funcall-interactively(find-file "~/path/to/ä-include.tex" t)
> command-execute(find-file)
> --8<---------------cut here---------------end--------------->8---
> 
> > You are aware that \303\244 is the UTF-8 sequence for ä, are you?
> 
> Yes, I'm aware of that.
> 
> > The above seems to mean that the search is done on a unibyte buffer or
> > something.
> 
> This is what I meant to say, thanks.  

Which is expected: latexenc-find-file-coding-system is called to
provide Emacs with a suitable encoding for decoding the contents of
the file.  It should be clear that the function is called _before_ the
contents is decoded, so the buffer is still unibyte, because Emacs
didn't yet decode it -- it doesn't yet know how.

IOW, this function is trying to solve a problem that cannot be solved
if the main file's name itself includes non-ASCII characters: we don't
know yet how to decode these characters.  We will only know that after
we read the main file, but for that we need to decode its name
correctly, and we can't.

So this can only work if the encoding of the main file's name is
easily determined from its byte sequence.  The patch below tries to
do the best we can.  It is still not 100% reliable: if the default
locale's encoding is not UTF-8, there are chances it will still not
work.  But I don't think there's a solution in that case, except by
providing the \inputencoding directive or the coding: cookie.

> I wrote this in my initial reply to this report:
> 
>   So I think `latexenc-find-file-coding-system' returns the wrong value
>   since Emacs hasn't set its coding for read properly when that function
>   kicks in.  I admit I'm not knowledgeable in this area, so my pretty
>   simple recommendation is to customize the variable
>   `file-coding-system-alist' and do something like this:
> 
>     (add-to-list 'file-coding-system-alist
>                  '("\\.\\(tex\\|ltx\\|dtx\\|drv\\)\\'" . prefer-utf-8))

Why not simply add a coding: cookie to the particular file?  It's
simpler, and doesn't affect other TeX/LaTeX files.

Here's the patch I can suggest:

diff --git a/lisp/international/latexenc.el b/lisp/international/latexenc.el
index 6e0cde6..1e0f8e7 100644
--- a/lisp/international/latexenc.el
+++ b/lisp/international/latexenc.el
@@ -160,6 +160,8 @@ latexenc-find-file-coding-system
                                      (stringp TeX-master)
                                      TeX-master)
                                 (bound-and-true-p tex-main-file)))))
+                ;; Decode the main file name as best as we can...
+                (setq file (decode-coding-string file 'undecided))
                 (dolist (ext `("" ,(if (boundp 'TeX-default-extension)
                                        (concat "." TeX-default-extension)
                                      "")
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.