TeXiFy not able to determine correct file/lineno from error log

[nealeyoung]

Type of JetBrains IDE (IntelliJ, PyCharm, etc.) and version

PyCharm 2024.1.4 (Professional Edition)
Build #PY-241.18034.82, built on June 24, 2024

Operating System

MacOS

TeXiFy IDEA version

0.9.7

What I did (steps to reproduce)

1. compiled a latex file that had an undefined command,

2. clicked on the error message in the "Log Messages" subsection of the console output.

Minimal example to reproduce the problem

\documentclass{article}

\setlength{\textheight}{3in}   % commenting this line out makes the problem go away

\newcommand{\filler}{
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
    Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
}
\begin{document}

    \filler

    \filler

    \filler

    \filler

    \filler

    \asd

\end{document}

Expected behavior

Pycharm should move the cursor to the line with the error.

Actual behavior

Pycharm doesn't move the cursor to the line with the error.

I'm assuming that the problem is with the parsing of the log. I'm guessing the line

[1{/usr/local/texlive/2024/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]

is somehow causing TeXiFy to lose track of the file that the error message is in. More specifically, when the log contains the following lines preceding the error, it doesn't work:

(./0_main.tex
LaTeX2e <2024-11-01> patch level 1
L3 programming layer <2024-12-25>
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/article.cls
Document Class: article 2024/06/29 v1.4n Standard LaTeX document class
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2024/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(/Users/neal/Desktop/mwe/out/0_main.aux)
[1{/usr/local/texlive/2024/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
./0_main.tex:23: Undefined control sequence.
l.23     \asd

When the log contains these lines (which happens for me if all text fits on a page), it does work:

(./0_main.tex
LaTeX2e <2024-11-01> patch level 1
L3 programming layer <2024-12-25>
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/article.cls
Document Class: article 2024/06/29 v1.4n Standard LaTeX document class
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2024/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(/Users/neal/Desktop/mwe/out/0_main.aux)
./0_main.tex:23: Undefined control sequence.
l.23     \asd

(if applicable) The full stacktrace of the exception thrown

[PHPirates]

Is it possible for you to update pycharm and try again with TeXiFy 0.9.9?
When I try your example, I see a correct line number, which should be line 22:

[nealeyoung]

I updated but still get the same error. Does your log show the following line?

[1{/usr/local/texlive/2024/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]

Or similar? It seems plausible that I am getting that log line as an artifact of my particular tex installation, in particular, because of whatever way the fonts were generated. I'm guessing it throws off the "file stack" in the part of the code that keeps track of which file each error message refers to.

[nealeyoung]

Here's the screenshot showing the raw output from the compilation.

[PHPirates]

You're right, I can reproduce the problem if I just input your log. Thanks for the example!

[nealeyoung]

Meanwhile, is there any short-term fix that I can use to work around this problem with the current version?

Maybe some customizable regular expression parameter to TeXiFy that I could change?

[PHPirates]

No, unfortunately the problem is not as easily fixed as with a regex change. The problem is related to how we implemented live parsing of the log: line by line but with a buffer of two lines, which is problematic if the error spans 3 lines, or if we need 3 lines to determine what belongs to a file path (a line could be broken up by the default line length).