Exclamation mark in logfile detected as Error instead of Bad Box

[jonschz]

Environment

• TeXstudio: 4.2.3
• Qt: 6.3.0
• OS: Windows 10
• TeX distribution: miktex

Expected behavior

My LaTeX file compiles without error ("process terminated normally") and produced a Bad Box with the following log entry:

[34]
Loose \hbox (badness 53) in paragraph at lines 149--150
[]\T1/lmr/m/sc/10.95 (+20) Remark \T1/lmr/m/n/10.95 (+20) 1.4.2\T1/lmr/m/sc/10.
95 (+20) . []\T1/lmr/m/n/10.95 (+20) A more abstract definition of $\U/bbm/m/n/
10.95 1[] \U/msa/m/n/10.95 ^^B \OML/lmm/m/it/10.95 X$ \T1/lmr/m/n/10.95 (+20) f
or $\OML/lmm/m/it/10.95 X [] \OT1/lmr/m/n/10.95 (+20) ([]) \OMS/lmsy/m/n/10.95 
! \OT1/lmr/m/n/10.95 (+20) ([])$ \T1/lmr/m/n/10.95 (+20) and
 []

Package cleveref Info: loaded `english' language definitions on input line 155.

I would expect the row starting with Loose \hbox [...] to show up as a Bad Box under "Errors and Warnings".

Actual behavior

The 7th row, starting with ! \OT1/lmr/m/n/10.95 [...], is detected as an Error and highlighted in red after compiling despite pdflatex terminating normally. I suspect it has to do with the row starting with an exclamation mark.

How to reproduce

I can provide a TeX file if needed.

[sunderme]

tex is notoriously bad for analysing errors in log as there is no well defined format for it. Tim basically gave up on this. You can provide the source code to provoke the error and we can hope that some one looks at it, but I will not. (without source code, we can directly close this issue.)

[jonschz]

Alright, I can imagine that parsing log files without a well-defined format is a pain. Nevertheless, here is the LaTeX file together with the full log file (the problem appears in line 578):

TexStudio_log_parsing_error.zip

I put in some effort to make this minimal, but I still had to keep in quite a list of packages. I also included the version numbers of imported packages whenever applicable.

[jonschz]

I have looked at the problem a little more closely and I have found some patterns:

• Most, but not all lines in a pdflatex log that start with an exclamation mark describe an error.
• It appears to me that TeXStudio interprets every line starting with an exclamation mark as an error.
• The logfile can't have any errors when pdflatex returns with exit code 0.
• For actual errors there seems to be a pattern regarding the lines before the exclamation mark:
  • In article.cls, it seems that every logged error is preceded by an empty line.
  • In book.cls, logged errors are either preceded by an empty line, or by an empty line followed by a line Chapter \d+\. (where "Chapter" changes based on the language).
  • I have not yet checked other common classes like KOMA-Script, though I expect that they could follow the same or similar patterns.

I see the following easy remedies:

1. Only interpret a row starting with an exclamation mark as an error if it is preceded by an empty row or by an empty row followed by a numbered chapter, e.g. match the regex \n\n(.+\d+\.\n)?! (with . not matching line breaks).
   • Pro: This will likely fix other false-positive log errors.
   • Con: Unless we are sure that this pattern applies to every logged error, we might introduce false negatives.
2. Leave the current error detection, but if pdflatex terminates with exit code 0, discard all error-level log entries.
   • Pro: This can't introduce false negatives.
   • Con: This does not help if the document contains other errors, or if an old logfile is read (hence we don't know the exit code).
3. Mixed approach: Generally follow Approach 1) unless pdflatex exits with an error and Approach 1) does not find a single error. In that case, just default to the old behaviour.
   • Pro: This remedies the false negative problem of Approach 1).
   • Con: This has disadvantages similar to those of Approach 2).

Any thoughts on this?

[deltakam]

does anyone know a workaround? For example, do not recognize it as an error if it contains particular string or something.. It's been quite frustrating since the synctex does not work when this happens.

[jonschz]

You could try to change the length of the command line output, see https://stackoverflow.com/q/1289680. This won't fix the issue for good, but it can decrease the odds and fix one particular instance of this error by moving the exclamation mark away from the beginning of the line.

Also, It'd be great if you could post a snippet of your log file. What the log file parser is missing (imo) is a collection of unit tests.

[deltakam]

Awesome! I managed to change it to have 2048 line width, so I am pretty sure it's not likely to happen again.

Unfortunately, I have edited further and at some point I stopped getting the false error. At this point, I don't have '!' at all in my log. I'll see if I can recover it.