LaTeX-Box asks for "main LaTeX file" when not editing LaTeX files.

[bsdbeard]

LaTeX-Box keeps asking to input the main LaTeX file even when you're not editing .tex, this is not only extremely annoying, but LaTeX box grabs keyboard input and won't let go until you kill vim.

Testcase:

:e my-latex-file.tex
:Latexmk
:enew

At this point the following function is recursively called:

    while !filereadable(l:file)
        let l:file = input('main LaTeX file: ', '', 'file')
        if l:file !~ '\.tex$'
            let l:file .= '.tex'
        endif
    endwhile

As you can see, the while loop does not end until you give it a .tex file, since the current working directory is not in a .tex project, you need to spend considerable effort to find a tex file just so you can make the loop stop! There is a b:main_tex_file variable checked by LaTeX-Box, however it is entirely useless as it's a buffer variable, as soon as you open a new buffer the variable is wiped!

This also sometimes happens when I quit vim with :q, before quitting this damn loop is called and won't shut down vim until I pick a .tex file, which is completely pointless as vim is going to shut down anyway!

Testcase2:

:e my-latex-file.tex
:Latexmk
:enew
" the input main tex file loop is called now, enter a file to regain control of vim
:e foo
:q
" the loop is called again even though I'm shutting down vim!

The most aggravating problem is that I do not understand what causes LaTeX-Box to call this function when I open a new buffer, there are no autocmds that do this, the only autocmd LaTeX-Box defines for non .tex files is in motion.vim and calls runtime plugin/matchparen.vim, which is harmless.

[lervag]

I'm curious: Does the same problem occur on my fork of LaTeX-Box? (There are substantial changes, but much of the code is still the same.)

I can understand that this is VERY annoying!

Edit: Fixed link.

[bsdbeard]

Does the same problem occur on my fork of LaTeX-Box

https://github.com/LaTeX-Box-Team/LaTeX-Box/issues/lervag/vim-latex

Is that the correct link? I get 404 this is not the web page you are looking for when I click that link.

[lervag]

Could you check what file type the new buffer has? (Either with something like :set filetype, echo &ft, or similar).

[bsdbeard]

Could you check what file type the new buffer has?

:set filetype

reports filetype=txt

[lervag]

That's very strange. The code you refer to should only run for tex buffers.

[bsdbeard]

I see you've edited the link, I've installed and tried your fork (ran :VimLatexCompile) and I did not have any problems. I will be using your fork from now on!

[Rmano]

It happens to me a lot too. I think that the common case is when I am editing a file in a project which is not a .tex file --- for example, if I open with gvim the two file main.tex and drawing.pgf, when I :update the second file a prompt come up asking for the main LaTeX file. I can stop it with Ctr-C, but it's quite annoying.

BTW --- what should I change to use lervag's fork? I think that anyway it would be better to find the bug and fix it... ;-)

[lervag]

Could you please describe exactly how to reproduce the bug?

[Rmano]

OK. So I start

gvim -p bgApuntesIntroEle.tex hojaAp_tikz.pgf

After that, in the .tex windows, I start compilation with preview with \ll. All is ok; then I switch to the other tab, do any modification, and hit F2 (I have it redefined as :update --- I can attach all the needed files if you need them --- is it possible to attach a .zip file here?) -> in this moment I have the "input main latex file" thing:

the garbage is from the usage of arrow keys when I do not notice the prompt.

The two files are:

\documentclass[a4paper,10pt]{article}

\usepackage{xltxtra}
\usepackage{tikz}
\usepackage[a4paper, landscape, top=0.5in, bottom=0.5in, left=0.5in, right=0.5in]{geometry}

\setromanfont[Mapping=tex-text]{Linux Libertine O}

\parindent=0pt\parskip=0pt
\pagestyle{empty}
\newcommand{\shot}{\vfill\hfill\input{hojaAp_tikz.pgf}\hfill\vfill\eject}
\begin{document}
\thispagestyle{empty}
\shot 
\end{document}

and

\begin{tikzpicture}[color=red!44!yellow]
\draw [very thick, rounded corners=20pt] (-1, -1) rectangle (25,17);
\draw [step=1,  style=dotted] (-0.1,-0.1) grid (24.1,16.1);
\draw (-0.1, 16.5) node [right] {R. Giannetti};
\draw (24.1, 16.5) node [left] {Introduction to Electric and Electronic Circuits --- DEA-SAP-135};
\end{tikzpicture}

with a local latexmkrc which is:

$pdflatex = "xelatex %O %S";

and a global .latexmkrc which is

$pdf_previewer = "start evince";
$pdf_update_method = 0;
$dvi_mode = 0;
$pdf_mode = 1;
$preview_continuous_mode = 1;

About vim, and the relevant (I think) .vimrc is

" F2 save and go back where we were 
nmap <F2> :update<CR>
vmap <F2> <Esc>:update<CR>
imap <F2> <c-o>:update<CR>

and

" LaTeX:
let g:tex_flavor='latex'
autocmd FileType tex set spell wrap linebreak
let g:LatexBox_latexmk_async=1
let g:LatexBox_latexmk_preview_continuously=1
let g:LatexBox_quickfix=2
let g:LatexBox_personal_latexmkrc=1

Please feel free to ask for more info. Thanks.

[lervag]

Ok, I think I understand what happens here: The async mode imples that an update of the pgf file leads to a compile command being issued through a callback. The callback is not intelligent, though: It issues a function call through the vimserver, and this function is called while the current buffer is the pgf file. But the pgf file does not inherently know the master tex file, and so it asks to get the master tex file as input.

I know a couple of things you can do to prevent this issue: First, you could name your main tex file main.tex. Or you could add a comment to the top of the file similar to tex root = <filename.tex>.

I think I will not try to implement a solution, unless someone sees a simple one. This is one of the main things I've "fixed" in my branch that I found too time intensive to backport. Fixed is quoted, since I ended up removing support for the async mode, and instead rely completely on the continuous mode of latexmk.

[Rmano]

Ok, I think I will try your branch. I do not see fancy to call all the main file the same ;-), and the comment thing could be nice but unfortunately the idea after including files is that they will be included from different main files...

One thing: effectively, if I simply comment out the let g:LatexBox_latexmk_async=1 thing from the .vimrc and keep the continuos preview, it seems that all is working ok. What am I losing here?

[lervag]

I think the async mode was first introduced in order to start a compilation with callbacks when the compilation was completed that opened the error window (if necessary), allowing you to work while the compilation was running. However, as the preview_continuously mode with the -pvc flag from latexmk was introduced to the code, the async mode is really no longer necessary (and is therefore removed from my version). This is because the -pvc mode makes latexmk run in the background and compile the document whenever necessary (any changed file), and in addition it automatically updates the pdf viewer if set up correctly.

Btw, I agree to your first comment, that the included files should not themselves generally specify where they are included. I've implemented a different strategy in my own branch where I instead search for files that have the current file included with \include{} or \input{}.

[Rmano]

Ok, found what happens. If I comment out the let g:LatexBox_latexmk_async=1, all is ok when all is going right, but if I have an error in the latex file, the error window is not shown. It either pass by silently or (if latexmk decides to stop) the main window still shows Compiling to PDF... and nothing happens.

[lervag]

Yes. As said, the async mode will make latexmk call a function in vim to open the errorwindow if there are errors after compilation. This function requires the filename for the main tex file, and asks for it.

[Rmano]

Ok --- please bear with me, it may be that I am dense. So it is not possible to have the errorwindow shows up and NOT have the noxious "Enter main TeX file" prompt? Would it works with your version? Thanks!

[lervag]

Correct: It is not possible to have the errorwindow show up without the "Enter main TeX file" prompt with LaTeX-Box at the moment in your specific example. The reason is that the function that opens the error file must first detect the main tex file. This is done in a function that tries several methods. The prompt is the final method, which means the first five methods failed, see here.

Note that one method that is supported is to create an empty file called some_file_name.tex.latexmain, where some_file_name.tex is the name of the main tex file.

And yes, this should work as expected with my version. I might backport my method, but I don't have very much time lately.