Sublime Forum

Issues with Latextools build panel

#1

This is a bit strange, since this problematic behaiour disappeared after a clean reinstall of ST and then reappeared again. Two problems which are maybe related, that’s why I put them together.
Build 4200 on Silicon Mac 15.6.1, Latextools 4.5.5

  1. After building a latex file (whether or not the compilation produces errors), if I issue from ST menu the command “Show Results Panel”, an empty panel is shown. If the Latextools panes was open, the empty panel is superimposed to it. Is this the intended behaviour? Shouldn’t it be Latextool Build Panel = Results panel = output.exec ?
    In any case, giving in the console the command
    window.run_command(“show_panel”, {“panel”: “output.exec”})
    fails silently
  2. If the compilation of a latex file produces errors, the build panel is open, errors are signaled, but the wrong file path is shown, pointing at
    /usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty:179:Undefined control sequence. [\aaa]
    The line number is correct (in this case, an undefined control sequence \aaa at line 179), but the path points at a system file. The command Next Result then opens the expl3.sty file at line 179.

Can anyone point me at the right direction to debug this? may this be related to the recent Latextools updates, or I should look into something else?

0 Likes

#2

LaTeXTools provides its own build runner command, which is inspired by but not related with ST’s default runner from Default/exec.py. Hence someone decided to use a dedicated output panel named “latextools”, long ago.

If a view with a LaTeX file is focused ctrl+esc key binding calls required command to open output.latextools panel.

The other option is to run LaTeXTools: Show build panel from Command Palette.

Where does the invalid sequence appear, actually?

LaTeXTools just parses build log. If it finds an error message, the file starting the block the error appears in is used as jump target.

Example:

(./my-userfile.tex
  ...
  (/usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty
  ...

  ! LaTeX error at line 179: undefined control sequence
  )
)

Such errors may be caused by incompatible package versions, being used.

0 Likes

#3

Thank you for your reply (and btw, for the amazing work! it helps hundreds of people).

About question 1: understood.

About question 2: Yes, that was my understanding, the log file is just parsed. That is why I am puzzled.

Everything works fine (jumping to the correct error line etc) if I compile a trivial file like

\documentclass{amsart}
\begin{document}
\aaa
\end{document}

But for more complex files, with a longer log file, the parser picks the wrong filename. I do not understand what might confuse the parser.
In my case, the log file contains indeed the line
(/usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty
at line 493, while the error appears at line 712:
\openout5 = 20251010-aaa.out
! Undefined control sequence.
l.179 \aaa

I am now making some tests with simpler and simpler tex sources to find the cuprit

0 Likes

#4

Update: the first line of my tex file contained the standard line
%!TEX program = lualatex

If I remove that line everything works perfectly. So I guess that directive interferes with the build system. Still I do not understand what was going wrong exactly.

0 Likes

#5

With regards to LaTeXTools’ issues there are many possible cases, which cause log parser to incorrectly detect (…) blocks, and thus cause wrong error location assignments. It sometimes seems to pick up unwanted brackets and treat them as blocks. If so build output sometimes also prints a warning like “Found errors while parsing log file …”.

The parser is the harder part of LaTeXTools’ code.

0 Likes

#6

I may have found the root cause of the problem.

  1. First of all, the problem occurs whenever lualatex is used; i can reproduce it also by building a minimal latex file with
    Compile to PDF - Traditional Builder with LuaTeX
    from the Latextools build selection panel. The Latextools parser chokes on the log file produced by lualatex.

  2. If I understand correctly, the parser maintains a list of files to keep track of the correct location of each error. The logic is based on the open and closed parentheses ( ) in the log file. Namely:

  • whenever tex opens a file, the log records a line
    (filepath/filename.ext
    starting with an open parenthesis. Then the parser pushes this file path on its stack
  • whenever tex closes the last opened file, it normally puts a line containing only a closed parenthesis as the first character. The parser checks for such lines and then it pops one file path off the stack

THE PROBLEM: this bit from the lualatex log:

(/usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty
Package: expl3 2025-09-02 L3 programming layer (loader) 
(/usr/local/texlive/2025/texmf-dist/tex/latex/l3backend/l3backend-luatex.def
File: l3backend-luatex.def 2025-06-09 L3 backend support: PDF output (LuaTeX)
\l__color_backend_stack_int=\count432
Inserting `l3color' in `luaotfload.parse_color'.))

Notice the two closing parentheses NOT at the beginning of the line. The corresponding bit in the pdftex log is

(/usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty
Package: expl3 2025-09-02 L3 programming layer (loader) 
(/usr/local/texlive/2025/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
File: l3backend-pdftex.def 2025-06-09 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count434
))

Notice the two parentheses AT THE BEGINNING of the line. In the first case, the expl3.sty path remains on the stack, in the second case it is dropped. Thus in the first case the parser wrongly associates the error lines with the expl3.sty file.

Summing up, one should fix the parser by relaxing the condition that the closing parentheses should be only at the beginning of lines. But this does not look trivial, since the log file contains a few other non-file-related closing parentheses, e.g.

Package biblatex Info: ... and expl3
(biblatex)             2025-09-02 L3 programming layer (loader) 
(biblatex)             is new enough (at least 2020/04/06),
(biblatex)             setting 'casechanger=expl3'.

Piero

P.S. on second thought, it may be easier, and also more legitimate, to ask the lualatex developers to stick to standards and log isolated parentheses to indicate closing files.

0 Likes