lervag / vimtex

VimTeX: A modern Vim and neovim filetype plugin for LaTeX files.
MIT License
5.54k stars 390 forks source link

Why is the log output of vimtex incomplete? #2136

Closed ThSGM closed 3 years ago

ThSGM commented 3 years ago

Description

Here is a minimal working example showing error log output using vimtex (above) versus Sublime Text and LaTexTools (below). As you can see the vimtex log doesn't show the location of the error of the missing brace in the \frac command.

I currently have the following error suppression settings:

let g:vimtex_quickfix_enabled=1
let g:vimtex_quickfix_mode=2
let g:vimtex_quickfix_autoclose_after_keystrokes=2

let g:vimtex_log_ignore = [
        \ 'Underfull',
        \ 'Overfull',
        \ 'specifier changed to',
        \ 'Token not allowed in a PDF string',
      \ ]
let g:vimtex_log_verbose = "1"

vimtexerror

Steps to reproduce

\documentclass{minimal}

\begin{document}
Hello world.

\begin{equation}
  \frac{1}{\sqrt{{1}}
\end{equation}
\end{document}

Expected behavior

Detailed relevant error log info.

Actual behavior

No response

Do you use a latexmkrc file?

NA

VimtexInfo

System info
  OS: Mac OS X 10.14.6 (18G9323)
  Vim version: NVIM v0.5.0
  Has clientserver: true
  Servername: /var/folders/qs/_xq028k12tjgp6btpj5rn3l40000gn/T/nvimw4gppn/0

VimTeX project: temp
  base: temp.tex
  root: /Users/tr/temp
  tex: /Users/tr/temp/temp.tex
  out: /Users/tr/temp/temp.pdf
  log: /Users/tr/temp/temp.log
  aux: /Users/tr/temp/temp.aux
  fls: /Users/tr/temp/temp.fls
  main parser: current file verified
  compiler: latexmk
    configuration: 
      continuous: 1
      callback: 1
      latexmk options:
        -verbose
        -file-line-error
        -synctex=1
        -interaction=nonstopmode
      latexmk engine: -pdf
    job: 4
    pid: 98659
    cmd: max_print_line=2000 latexmk -verbose -file-line-error -synctex=1 -interaction=nonstopmode -pdf -pvc -view=none -e '$success_cmd = ($success_cmd ? $success_cmd . " ; " : "") . "echo vimtex_compiler_callback_success"' -e '$failure_cmd = ($failure_cmd ? $failure_cmd . " ; " : "") . "echo vimtex_compiler_callback_failure"' 'temp.tex'
  viewer: Skim
  qf: LaTeX logfile
    root: /Users/tr/temp
    addqflist: 321
    fix_paths: 322
    main: /Users/tr/temp/temp.tex
    set_errorformat: 320
  document class: minimal
lervag commented 3 years ago

Here is a minimal working example showing error log output using vimtex (above) versus Sublime Text and LaTexTools (below). As you can see the vimtex log doesn't show the location of the error of the missing brace in the \frac command.

I also can't see that Sublime Text and LaTexTools shows the location. I do see that they provide a better error message. However, it is actually very hard to properly parse the .log files for good errormessages, and so it is more or less impossible to use Vim's errorformat mechanism to achieve the same level of the error log in this case.

A possibility is to use a different quickfix method, see :help g:vimtex_quickfix_method. I just tested pplatex, and it does show more of the error message (but it looses the filename location).

ThSGM commented 3 years ago

Hi @lervag. Thanks for your work as ever.

I also can't see that Sublime Text and LaTexTools shows the location. I do see that they provide a better error message. However, it is actually very hard to properly parse the .log files for good errormessages, and so it is more or less impossible to use Vim's errorformat mechanism to achieve the same level of the error log in this case.

I can try and find a better minimal example where the Sublime Text/LaTeXTools does show the line number, but it does seem to be subject to the exact layout of the .tex file. In any case, I think the point is made---the error reporting is not very good.

Without being flippant, why is LaTeXTools so much better at parsing the log file? The same comment is made for Mac's TexShop:

Screenshot 2021-08-17 at 10 54 00

A possibility is to use a different quickfix method, see :help g:vimtex_quickfix_method. I just tested pplatex, and it does show more of the error message (but it looses the filename location).

I looked into both pplatexand pulp this morning. However, both require building from source on my Mac, and I have struggled with both installs. Perhaps I can try to ask the creators to provide binaries for MacOS, but both codes are also not actively maintained it seems.

But then even if I can sort out the build errors, in my view this is a fairly significant limitation of vimtex---if the error output can't match even basic conventional latex compilers like TexShop or LaTeXTools (on Mac). I am not sure about compilers like Kile, TexStudio, TexMaker, etc. but I would have thought their outputs would be similar as well?

ThSGM commented 3 years ago

Also:

It seems that texfot will do a better job and comes packaged with TexLive, see StackExchange.

On the log file, it returns


/Library/TeX/texbin/texfot: invoking: pdflatex temp.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) (preloaded format=pdflatex)
Runaway argument?
{\sqrt {{1}} \end {equation} \par \end {document}
! File ended while scanning use of \frac .
<inserted text>
! Emergency stop.
<inserted text>
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on temp.log.

A built-in alternative or one that is packaged with most latex installs would be much better.

lervag commented 3 years ago

I can try and find a better minimal example where the Sublime Text/LaTeXTools does show the line number, but it does seem to be subject to the exact layout of the .tex file. In any case, I think the point is made---the error reporting is not very good.

Yes; the problem is that the quickfix feature in Vim typically relies on the errorformat option for parsing output to errors/warnings. I believe I've implemented a very good parser based on errorformat in VimTeX, but it is very clearly limited. The LaTeX log output is hard to parse. And this is why I do not even want to try to solve your original problem here directly.

Without being flippant, why is LaTeXTools so much better at parsing the log file?

It's a good question. Either someone has implemented a good parser in LaTeXTools, or they rely on some preprocessor that I'm not aware of. I mean, it could even just be pplatex. It would be interesting to know, so if you were to look into it I would be happy to hear. Or if anyone else is reading this that knows.

The same comment is made for Mac's TexShop:

Well, I don't quite agree: TexShop is only showing you the log output here. You can see similar output in VimTeX with \lo (which shows the latexmk output), or by opening the .log file directly. That is, I believe in this case you are sort of comparing apples to oranges.

I looked into both pplatexand pulp this morning. However, both require building from source on my Mac, and I have struggled with both installs.

Yes, I can relate to this. pplatex installs just fine on my Linux, but pulp is harder and I was not able to install it when I tried today. I did not spend long investigating, but I noticed there was an open issue with the same problem I had.

But then even if I can sort out the build errors, in my view this is a fairly significant limitation of vimtex---if the error output can't match even basic conventional latex compilers like TexShop or LaTeXTools (on Mac). I am not sure about compilers like Kile, TexStudio, TexMaker, etc. but I would have thought their outputs would be similar as well?

Yes and no: I believe you will find that VimTeX handles most types of warnings and errors quite fine. The error in your example, where you are missing a }, is particularly hard, actually. This is evident also from the LaTeX log file, which does not even properly specify the line where the problem occurs.

It seems that texfot will do a better job and comes packaged with TexLive

That's interesting. But it's slightly hard to use, because it parses the standard output instead of the log file. The quickfix parsing is currently based on parsing the log file or a preprocessed version of the log file.

On the log file, it returns

Again, notice how even here the error message does not contain the relevant line number.

lervag commented 3 years ago

I've tried to improve the handling now. Please test.

ThSGM commented 3 years ago

That seemed to do the trick---at least for this error. Excellent!

Thanks as well for explaining the issues clearly to me.

lervag commented 3 years ago

Happy to hear it! Let's hope I didn't break anything in the process. I spent quite a lot of time on improving the related tests to avoid just that :p

lervag commented 3 years ago

By the way, feel free to open related issues if you happen to notice other types of log output that is not well parsed. As I said, the parsing is hard, but there are quite a few hackish tricks that can help.

ThSGM commented 1 year ago

@lervag

I wanted to return to this issue as today I was getting very frustrated with the poor error parsing. This happens frequently where I may need to open up the tex file with a different parser in order to read the issue.

Is there any way to just ensure the quickfix output includes a copy of the log file near the error? I would much prefer more output.

lervag commented 1 year ago

I wanted to return to this issue as today I was getting very frustrated with the poor error parsing. This happens frequently where I may need to open up the tex file with a different parser in order to read the issue.

If you are able to make a simple, reproducible example of a situation in which you find the error parsing to be poor, then I may be able to help improve it. If so, please open a new issue for that.

Is there any way to just ensure the quickfix output includes a copy of the log file near the error? I would much prefer more output.

You can always just open the log file. Or you can do \lo (or :VimtexCompileOutput) to open the latexmk output which typically also contains most of the log output.