GNU bug report logs - #28953
11.91.0; wrong alert about inexistent LaTeX errors

unarchive 28953

From: jfbu <jfbu <at> free.fr>
To: bug-auctex <at> gnu.org
Subject: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Mon, 23 Oct 2017 11:11:28 +0200

Hi, here is minimal example:

\documentclass{article}
\begin{document}
\typeout{Hello:1: }
\end{document}

This triggers AUCTeX log parser to report wrongly
that there were compilation errors.

The two colons and the space conspire to this result.

It happened in real life example.

Best,

Jean-François

From: Mosè Giordano <mose <at> gnu.org>
To: jfbu <jfbu <at> free.fr>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Mon, 23 Oct 2017 14:42:37 +0200

Hi Jean-François,

2017-10-23 11:11 GMT+02:00 jfbu <jfbu <at> free.fr>:
> Hi, here is minimal example:
>
> \documentclass{article}
> \begin{document}
> \typeout{Hello:1: }
> \end{document}
>
> This triggers AUCTeX log parser to report wrongly
> that there were compilation errors.
>
> The two colons and the space conspire to this result.
>
> It happened in real life example.

I think you're asking too much :-)  I don't see any meaningful way to
distinguish between a real error and a message you write to the log
that is exactly equal to the file-line-error style.  The same happens
with \typeout{! hello world}.

Bye,
Mosè

From: jfbu <jfbu <at> free.fr>
To: Mosè Giordano <mose <at> gnu.org>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Mon, 23 Oct 2017 14:47:24 +0200

Hi Mosè

Le 23 oct. 2017 à 14:42, Mosè Giordano <mose <at> gnu.org> a écrit :

> Hi Jean-François,
> 
> 2017-10-23 11:11 GMT+02:00 jfbu <jfbu <at> free.fr>:
>> Hi, here is minimal example:
>> 
>> \documentclass{article}
>> \begin{document}
>> \typeout{Hello:1: }
>> \end{document}
>> 
>> This triggers AUCTeX log parser to report wrongly
>> that there were compilation errors.
>> 
>> The two colons and the space conspire to this result.
>> 
>> It happened in real life example.
> 
> I think you're asking too much :-)  I don't see any meaningful way to
> distinguish between a real error and a message you write to the log
> that is exactly equal to the file-line-error style.  The same happens
> with \typeout{! hello world}.
> 
> Bye,
> Mosè

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.

Best,
Jean-François

From: Mosè Giordano <mose <at> gnu.org>
To: jfbu <jfbu <at> free.fr>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Mon, 23 Oct 2017 17:09:57 +0200

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 ;-)

Bye,
Mosè

From: jfbu <jfbu <at> free.fr>
To: Mosè Giordano <mose <at> gnu.org>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Mon, 23 Oct 2017 18:35:04 +0200

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?

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?

If return code is 0, it could then say something like "Log file
contains data looking like errors, but LaTeX run ended with return
code 0". For my example above, with \ERROR commented out,
the return code is 0.

This is why I asked about documentation about the minimal used
regex, because perhaps these were considered already and dismissed
for some reason.

Bye,

Jean-François

From: Mosè Giordano <mose <at> gnu.org>
To: jfbu <jfbu <at> free.fr>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Tue, 24 Oct 2017 00:24:55 +0200

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è

From: jfbu <jfbu <at> free.fr>
To: bug-auctex <at> gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Tue, 24 Oct 2017 09:25:30 +0200

Le 24/10/2017 à 00:24, Mosè Giordano a écrit :
> The file may end with an extension (AUCTeX doesn't really like
> files without any extension), but TeX doesn't require it at all.

Hi Mosè, you are right. What about spaces? I know there isn't
a single file with spaces in its path on my TeX installation,
and I personally will never ever attempt to use such in my
TEXMFHOME or in the document repertory or sub-repertories.

Unfortunately I never informed myself about status of spaces
in file names with TeX, because they just don't belong to
my world.

Checking for spaces in the string before :<line number>: would
have avoided my real-life problem.

For concreteness the issue arose because often one uses labels
of the type eq:1, thm:3, etc... (indeed possibly AUCTeX prompts
user to insert such label) and my package was reporting them
in a log message of the type

"Undefined label <the label here>: rerun Latex."

Thus checking for space before would have avoided false-positive.

I fixed my real-life problem by simply avoiding adding an
extra colon.

People doing

\section{foo}\label{sec:1: (authorA)}

See \ref{sec:1: (authorA)}

will similarly get bitten by this problem.

In some parallel universe, maybe it happened before I cooked
up that example.

Bye,
Jean-François

From: Mosè Giordano <mose <at> gnu.org>
To: jfbu <jfbu <at> free.fr>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Wed, 25 Oct 2017 00:59:25 +0200

2017-10-24 9:25 GMT+02:00 jfbu <jfbu <at> free.fr>:
> What about spaces? I know there isn't
> a single file with spaces in its path on my TeX installation,
> and I personally will never ever attempt to use such in my
> TEXMFHOME or in the document repertory or sub-repertories.

TeX and AUCTeX don't have problems with spaces in file names.  I also
avoid spaces in file names, but asking people to completely stop using
spaces in order to make AUCTeX work doesn't look good.

> People doing
>
> \section{foo}\label{sec:1: (authorA)}
>
> See \ref{sec:1: (authorA)}
>
> will similarly get bitten by this problem.

Are there really people mixing numeric style and literal style in
labels? :-)  Using anything beside [a-zA-Z0-9-:] in LaTeX labels is
usually a bad idea, just because there are packages playing with
catcodes.  For example, underscores are legal in labels, but there are
cases where you can get into troubles if you use them, see for example
https://tex.stackexchange.com/q/121416/31416 or
https://tex.stackexchange.com/a/18312/31416.

Bye,
Mosè

From: jfbu <jfbu <at> free.fr>
To: Mosè Giordano <mose <at> gnu.org>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Wed, 25 Oct 2017 09:57:36 +0200

Hi Mosè

Le 25/10/2017 à 00:59, Mosè Giordano a écrit :
> 2017-10-24 9:25 GMT+02:00 jfbu <jfbu <at> free.fr>:
>> What about spaces? I know there isn't
>> a single file with spaces in its path on my TeX installation,
>> and I personally will never ever attempt to use such in my
>> TEXMFHOME or in the document repertory or sub-repertories.
> 
> TeX and AUCTeX don't have problems with spaces in file names.  I also
> avoid spaces in file names, but asking people to completely stop using
> spaces in order to make AUCTeX work doesn't look good.
> 
>> People doing
>>
>> \section{foo}\label{sec:1: (authorA)}
>>
>> See \ref{sec:1: (authorA)}
>>
>> will similarly get bitten by this problem.
> 
> Are there really people mixing numeric style and literal style in
> labels? :-)  Using anything beside [a-zA-Z0-9-:] in LaTeX labels is
> usually a bad idea, just because there are packages playing with
> catcodes.  For example, underscores are legal in labels, but there are
> cases where you can get into troubles if you use them, see for example
> https://tex.stackexchange.com/q/121416/31416 or
> https://tex.stackexchange.com/a/18312/31416.

--- start of slightly off-topic LaTeX considerations

As is explained in the answer by HO:

> Usually the underscore with its standard catcode "subscript" (8) does
> not cause problems, if used inside \label or \ref:
> 
> [...]
> 
> Also shorthands of package babel are not a problem, because babel
> patches the \label/\ref system to add support for shorthands.

Any package making  a character like the underscore globally
active without at the same time using the babel patches for making
it safe in \label/\ref would simply be a buggy package.
HO does end his answer with the "underscore" package and mentions
that package is a good citizen.

A user making the underscore globally active with no further
ado is simply breaking LaTeX and not informed enough.

Notice that babel-french turns the colon : into an active
character, of course in a way compatible with babel's mechanism.
This mechanism is applied by hyperref package in \href parsing.

Ironically, there are issues with xelatex/lualatex where babel-french
does *not* use active characters at all; because the babel
mechanisms do not apply, the behaviour of \href is unexpected.
Very recently indeed, babel-french maintainer pushed a
fix to CTAN to handle that specific issue.

> Version:  3.3d  2017-10-19
> 
>  Slight change for LuaTeX only:
> 
>  The automatic insertion of non-breaking spaces before the colon
>  character has been improved: a spurious space is no longer inserted
>  in strings like "http://mysite", "C:\textbackslash Program Files"
>  or "10:55".

Regarding that piece of the answer by egreg

> Warning. Some characters might give problems when babel is loaded
> along with varioref (for example the colon : with French and the
> double quote " with many languages). Without varioref these should be
> OK. As Martin points out, some packages might redefine _, making it
> unusable in labels.

it indicates a bug of varioref, that's all.

--- end of off-topic digression

Now,AUCTeX prompts user at each equation insertion with

(Optional) What label: eq:

now in a paper when it is not sure in advance which
equations one will link to, one is not going to invent
a name each time, and simply using numeric labels eq:1,
eq:2, is rather natural and I am sure people do this.

Or am I really as bezerk I tend to believe, years passing by?

I do agree AUCTeX is still rather robust here because even
using eq:1: as label appears to be ok, problems may arise
when having a space after the second colon.

As people have not complained too much on this issue it
is to some extent indication indeed that AUCTeX's minimal
regex to identify error messages is quite effective.

About

> TeX and AUCTeX don't have problems with spaces in file names.

Are spaces escaped in anyway when writing a filename to log?
Unfortunately, here it is not only TeX from TeXBook but rather
also the pdfTeX etc... rules which matters:

They introduced the
filename:linenumber: notation,
dropping the !<space> at start of line thus making log-parsing
more difficult. Perhaps they could have used a

! filename:linenumber: error

format, but would have this broken expectations from other contexts?

Best

Jean-François

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Mosè Giordano <mose <at> gnu.org>, jfbu <jfbu <at> free.fr>
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Thu, 16 Jun 2022 20:57:04 +0900

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è

From: jfbu <jfbu <at> free.fr>
To: bug-auctex <at> gnu.org
Cc: 28953 <at> debbugs.gnu.org
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Thu, 16 Jun 2022 14:42:16 +0200

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

From: jfbu <jfbu <at> free.fr>
To: Mosè Giordano <mose <at> gnu.org>
Cc: 28953 <at> debbugs.gnu.org, Ikumi Keita <ikumi <at> ikumi.que.jp>
Subject: Re: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Thu, 16 Jun 2022 15:27:28 +0200

Hi Mosé, (replying about 56 months later)

> 
> Le 24 oct. 2017 à 00:24, Mosè Giordano <mose <at> gnu.org> a écrit :
> 
> 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.
> 

about this:

> 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

Only to point out that it is core TeX behaviour in errorstopmode:
(quoting from tex.web sources:)

> The print_err procedure supplies a ‘!’ before the official message, and makes sure that the terminal is awake if a stop is going to occur. 
> 
> @ The global variable |interaction| has four settings, representing increasing
> amounts of user interaction:
> 
> @d batch_mode=0 {omits all stops and omits terminal output}
> @d nonstop_mode=1 {omits all stops}
> @d scroll_mode=2 {omits error stops}
> @d error_stop_mode=3 {stops at every opportunity to interact}
> @d print_err(#)==begin if interaction=error_stop_mode then wake_up_terminal;
>   print_nl("! "); print(#);
>   end

Any LaTeX \PackageError ultimately goes through TeX’s \errmessage and \errhelp mechanisms.

But the change file tex.ch implements -file-line-error option and this is relevant:

> @x [6.73] l.1734 - file:line:error style error messages.
>   print_nl("! "); print(#);
> @y
>   if file_line_error_style_p then print_file_line
>   else print_nl("! ");
>   print(#);
> @z

The procedure print_file_line has coding

> procedure print_file_line;
> var level: 0..max_in_open;
> begin
>   level:=in_open;
>   while (level>0) and (full_source_filename_stack[level]=0) do
>     decr(level);
>   if level=0 then
>     print_nl("! ")
>   else begin
>     print_nl (""); print (full_source_filename_stack[level]); print (":");
>     if level=in_open then print_int (line)
>     else print_int (line_stack[level+1]);
>     print (": ");
>   end;
> end;

Some other relevant pieces from tex.ch from web2c 

> % Plus, it's nicer just to do an exit with the appropriate status code
> % under Unix.  We call it `uexit' because there's a WEB symbol called
> % `exit' already.  We use a C macro to change `uexit' back to `exit'.

> @d do_final_end==begin
>    update_terminal;
>    ready_already:=0;
>    if (history <> spotless) and (history <> warning_issued) then
>        uexit(1)
>    else
>        uexit(0);
>    end

and from tex.web:

> @d spotless=0 {|history| value when nothing has been amiss yet}
> @d warning_issued=1 {|history| value when |begin_diagnostic| has been called}
> @d error_message_issued=2 {|history| value when |error| has been called}
> @d fatal_error_stop=3 {|history| value when termination was premature}

which is probably related to the exit status returned by binary
in case \errmessage has been made used of

Cheers,

Jean-François

GNU bug report logs - #28953 11.91.0; wrong alert about inexistent LaTeX errors

GNU bug report logs - #28953
11.91.0; wrong alert about inexistent LaTeX errors