GNU bug report logs -
#28953
11.91.0; wrong alert about inexistent LaTeX errors
Previous Next
Reported by: jfbu <jfbu <at> free.fr>
Date: Mon, 23 Oct 2017 09:45:02 UTC
Severity: normal
Found in version 11.91.0
Done: Ikumi Keita <ikumi <at> ikumi.que.jp>
Bug is archived. No further changes may be made.
Full log
Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Keita and Mosè,
OK with me, thanks
I noticed in 2017 I wrote
> I plan to look at it when I get time to make
> concrete proposal.
Obviously I never got time...
As per my original problem it had occurred in a LaTeX package of mine
and I fixed it there via avoiding using \ref with some argument
including a ":", which I replaced with a full stop "." rather.
This is why, probably, I did not bother more, sorry...
Best,
Jean-François
Le 16/06/2022 à 13:57, Ikumi Keita a écrit :
> Hi Mosè and Jean,
>
> I've forgotten this bug, but came across it just now. I expect it was
> fixed recently together with bug#55065[1].
>
> Is it OK to close this bug?
>
> Bye,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine
>
> [1] https://lists.gnu.org/r/bug-auctex/2022-04/msg00013.html
>
>>>>>> Mosè Giordano <mose <at> gnu.org> writes:
>> 2017-10-23 18:35 GMT+02:00 jfbu <jfbu <at> free.fr>:
>>>
>>> Le 23 oct. 2017 à 17:09, Mosè Giordano <mose <at> gnu.org> a écrit :
>>>
>>>> 2017-10-23 14:47 GMT+02:00 jfbu <jfbu <at> free.fr>:
>>>>> In real life example the ``:1: `` pattern appeared farther away on the line
>>>>> inside a sentence. To a human, it is obvious it is not a LaTeX error
>>>>> message. I am confident the logic for recognizing such error messages
>>>>> is improvable. I plan to look at it when I get time to make
>>>>> concrete proposal.
>>>>
>>>> The relevant regexp is at line 1507 of tex-buf.el:
>>>> https://git.savannah.gnu.org/gitweb/?p=auctex.git;a=blob;f=tex-buf.el;h=f458651c2cffc110ef4af4541c6b08af976907fb;hb=HEAD#l1507
>>>> Perhaps ".*" is too greedy, anyway that regexp should match anything
>>>> that is a legal path. I don't expect it to be supereasy to find a
>>>> regexp matching a path but not a whole sentence ;-)
>>>
>>>
>>> Indeed. But the regexp is really minimal, is there some documentation
>>> about the underlying difficulties?
>
>> I don't think there is such documentation, but I'd be happy to be proven wrong.
>
>> As far as I know, using exclamation mark to start an error message is
>> just a widespread convention, there is nothing fundamental in it. For
>> the file-line-error style, the first part should match a file path. I
>> don't know if it **has** to start with "./" (or "/"), or it may change
>> depending on the TeX version (and for sure it depends on the platform
>> used). The file may end with an extension (AUCTeX doesn't really like
>> files without any extension), but TeX doesn't require it at all.
>
>>> Reporting that the LaTeX run had errors, and giving an Error overview
>>> could perhaps be split.
>>>
>>> For example if I try this
>>>
>>> \documentclass{article}
>>> \begin{document}
>>> Hi
>>> \typeout{./I/am/not/a/file:4: and this is not an error}
>>> \typeout{}
>>> \ERROR
>>> \typeout{}
>>> \typeout{! I am not an error.}
>>>
>>> Did it go OK?
>>> \end{document}
>>>
>>> with Latexmk, it will only say
>>>
>>> Collected error summary (may duplicate other messages):
>>> latex: Command for 'latex' gave return code 1
>>> Refer to 'temp2.log' for details
>>>
>>> Without the \ERROR, it reports no problem. Now, indeed
>>> Latexmk does not report a detailed error summary like AUCTeX
>>> (it does report undefined references etc...)
>>>
>>> For example a \PackageError{foo}{zaza}{tata} will also
>>> cause the latex run to exit with return code 1 on my mac os,
>>> hence the return code detects it independently of log contents.
>>>
>>> Could AUCTeX check the return code on platforms allowing it?
>
>> This is interesting, but should be implemented in a reliable way.
>
>> Bye,
>> Mosè
>
>
>
> _______________________________________________
> bug-auctex mailing list
> bug-auctex <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-auctex
This bug report was last modified 2 years and 334 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.