Hi Miguel and all, >>>>> "Miguel V. S. Frasson" writes: > I am editing a simple text with actually no errors. Compilation reports > errors (what is annoying) but TeX-next-error says "No more errors." > MWE: > \documentclass{article} > \begin{document} > Bla :123: > blablabla-blablabla blablabla-blablabla > blablabla-blablabla blablabla-blablabla. > \end{document} > Investigating, in tex-buf.el one reads: > (if (re-search-forward "^\\(!\\|.*:[0-9]+:\\) " nil t) > (progn > (message "%s errors in `%s'. Use %s to display." name (buffer-name) > (substitute-command-keys > "\\\\[TeX-next-error]")) > so error message can be triggered as easily as if input has a string like > ":0: " that can go to log if that line has a bad break, like in MWE. Thanks for the report with simple MWE. I can confirm the behavior. To developers: (1) I think the attached patch circumvents this issue. However, `TeX-parse-error' contains similar loose treatments for other messages from (La)TeX. Should we add refinements to the rest of the function as well? (2) (This item isn't related to my patch; it has persisted with AUCTeX for fairly long period.) Looking at the regexp used in `TeX-parse-error', the parts "Hook to change line numbers" and "Hook to change file name" are not actually matched because preceding alternative parts "New file" and "End of file" match instead. Thus the accompanying codes at later part of the function never run, IIUC: ---------------------------------------------------------------------- ;; Hook to change line numbers ((match-beginning 5) (setq TeX-error-offset (list (string-to-number (TeX-match-buffer 5)))) t) ;; Hook to change file name ((match-beginning 6) [...] ---------------------------------------------------------------------- Is that OK? Or am I missing something? Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine