Some problems with the TOC

[petobens]

Great work on the new toc that doesn't need aux files! There are a few thing I noticed:

i) Consider the case where without generating aux files one has a_main_file.tex:

\documentclass{book}
\begin{document}
  \include{bar}
  \include{foo}
\end{document}

where bar.tex is

\section{Bar section}
\label{sec:bar_section}

and foo.tex is

\section{Foo section}
\label{sec:foo_section}

If for instance I call latex#toc#toggle() on either bar.tex or foo.tex the TOC only shows the sections corresponding to each file and not both of them (maybe this is related to #16)

ii) the first time I call latex#toc#toggle() from the main file it complains that it cannot read the included files like this

Error in latex#toc s:parse_files:
File not readable: ..../foo.tex

but when called again it works

iii) if in the preamble I have some command that uses \section{#1} like:

\newcommand*{\secappendix}[1]{%
  \setcounter{section}{0}%
  \renewcommand*{\thesection}{\appendixname\space\thechapter.\Alph{section}}%
  \renewcommand*{\theHsection}{\thechapter.\Alph{section}}%
  \section{#1}\renewcommand*{\thesection}{\thechapter.\Alph{section}}%
}

it shows in the TOC as a new section. Section commands in the preamble should be ignored.

iv) When I open the TOC I want focus to be in the TOC buffer (i.e place cursor there). Is there a way to achieve that?

[lervag]

I think the main problem here is related to the identification of the main file. I suspect that, for some reason, the main file is not detected in your case. This is as you describe in #16.

To verify this, could you open the three files in the same vim session (use hidden buffers), then show me the output of \li. Ideally, it should only show one data entry for the main file. I suspect that it will show three entries, one for each file. The data blobs are explained in the documentation; there should only be one global data entry for each main latex file. Secondary latex files do not have such data entries, but rather point to the main file data entry.

[petobens]

If I open the three files by opening the main file first (i.e I first run :e ../a_main_file.tex and only then run :e ../bar.tex and :e ../foo.tex) it seems to work perfectly. The output of \li, when called from bar.tex, shows only one data entry for the main file (as seen in the first image).

However the problems appear if:

i) I only open the bar.tex file then there is no indication whatsoever of the main file (as seen in the second image). With Latex-Box I can run :echo fnameescape(LatexBox_GetMainFileName()) from bar.tex and it will return the main file. When I run echo g:latex#data[b:latex.id].tex in vim-latex it returns .../bar.tex.

ii) I open the three files but I first open a file other than the main file (i.e I run either :e ../bar.tex or :e ../foo.tex before :e ../a_main_file.tex) then the output of \li shows two entries: (a) the first file that was opened (in my case bar.tex) and (b) the mainfile (this can be seen in the third image)

[lervag]

Hi. First: Sorry that I'm taking so long on this. I'm on vacations, and I don't have that much time for vim-latex right now.

Just so we're clear: echo fnameescape(LatexBox_GetMainFileName()) from LaTeX-Box is equivalent to echo g:latex#data[b:latex.id].tex. Thus it seems that we're dealing with some sort of bug. The main file is found by the function s:get_main() in autoload/latex.vim. Note, however, that compared with LaTeX-Box, this function is only called ONCE (which is why it is a private function s:...) and the value is stored in the data blob.

Note also that the data blob allows several entries. This makes it possible to work with several latex projects at the same time. This is also the reason why the b:latex_id variables exist, because each tex buffer must be related to a g:latex#data entry. This also explains how a project with several files can exist and only have one g:latex#data entry.

Now, I am not able to reproduce your issue. I suspect the issue might have something to do with windows, but I am not sure. It would be very helpful if you could try to look into it a little bit on your own. That is, I am relatively sure that the problem is with s:get_main_recursive. The function is not too long, and it should not take very much effort to understand what it does. I hope.

An "easy way out" would be for you to start using the % Texroot = ... specifiers at the top of the file, as this should also work on windows.

[petobens]

This is strange. If I copy the s:get_main_recurse() function to my vimrc like this:

function! GetMainFile(file)
    " Check if file is readable
    if !filereadable(a:file)
        return 0
    endif

    " Check if current file is a main file
    if len(filter(readfile(a:file),
        \ 'v:val =~ ''\C\\begin\_\s*{document}''')) > 0
        return fnamemodify(a:file, ':p')
    endif

    " Search for files that include the current file
    for l:file in split(glob('*.tex')) + split(glob('../../*.tex'))
        if len(filter(readfile(l:file), 'v:val =~ ''\v\\(input|include)\{'
            \ . '((.*)\/)?'
            \ . fnamemodify(a:file, ':t:r') . '(\.tex)?''')) > 0
            return GetMainFile(l:file)
        endif
    endfor

    " If not found, return 0
    return 0
endfunction

and run echo GetMainFile(expand('%:p')) from bar.tex then it correctly returns C:/Users/Pedro/Desktop/test/a_main_file.tex. However when I using that function from the plugin (with echo g:latex#data[b:latex.id].tex) then it fails.

The problem is in fact s:get_main_recurse(). If I modify s:get_main() function to return get_main_recurse() like this

function! s:get_main()
    let main = s:get_main_recurse(expand('%:p'))
    return main
endfunction

and change the last line of get_main_recurse() from

return 0

to

return 'file recurse is not finding main file`

Then echo g:latex#data[b:latex.id].tex returns file recurse is not finding main file.
I don't understand why it works when copied to my vimrc but fails within the plugin.

[petobens]

When trying to find where is the problem related to the main file I think I also found another problem (at least with my settings). With the following minimal vimrc

set nocompatible

let $ONEDRIVE_HOME = expand('C:/OD/Users/Pedro/')
let $DOTVIM = expand('$ONEDRIVE_HOME/vimfiles')

set runtimepath=$DOTVIM,$VIMRUNTIME
set runtimepath+=$DOTVIM/bundle/vim-latex-test/

filetype plugin indent on
let g:tex_flavor = 'latex'

If I open bar.tex and run echo latex#info() I get the errors seen in the image. This should not give errors?

[petobens]

Changing to the current directory before searching for files that include the current file seems to solve the problem!

iii) and iv) of my first post and the undefined variable problem of the last comment are still unsolved.

If you want I can open a new issue (or two new issues) with those problems.

Happy holidays btw!

[lervag]

I would be happy if you could open new issues for iii) and iv). I think both of those can be solved relatively easily.

Regarding your last comment, could you ensure that the filetype is tex and not plaintex when you open bar.tex? If the filetype is indeed tex, could you follow up by adding an echo to s:init_environment to ensure that it is actually called. If so, does the b:latex dictionary exist?

[petobens]

Do you mean setting echo s:init_environment() instead of call s:init_environment() in latex#init() function? I did that but I don't get any errors when opening bar.tex (which is inded a tex file according to :set ft?) but I do get the previous error when running echo latex#info().

I think I'm not following your instructions properly. Sorry about that. Could explain them again?

Note that this is something that doesn't affect my workflow at all, I just noticed it when using a minimal vimrc and thought it was worth mentioning.

[lervag]

Sorry, my explanation was not good enough. I meant that you should add

echomsg "Hello World"

At the top of the function s:init_environment() in the file autoload/latex.vim, to verify that the function actually runs.

In the meantime I've realized that the problem is g:latex_enabled, which must be set to nonzero in your vimrc to enable vim-latex.

[petobens]

The problem only appear with a minimal vimrc like this (where latex files are indeed recognized as tex files and vim-latex is enabled):

    set nocompatible

    let $ONEDRIVE_HOME = expand('C:/OD/Users/Pedro/')
    let $DOTVIM = expand('$ONEDRIVE_HOME/vimfiles')

    set runtimepath+=$DOTVIM/bundle/vim-latex-test/

    filetype plugin indent on

    augroup ft_tex
        au!
        autocmd BufNewFile,BufReadPost *.tex set filetype=tex
    augroup END

I added the echomsg "Hello World" at the top the function and it seems that the functions doesn't actually run.

Just forget about this, it is something that really doesn't affect my workflow at all.

[petobens]

Thanks for adding the message indicating that "vim-latex has not been initialized!".
How can I initialized vim-latex using the minimal vimrc of my previous comment?

[lervag]

Ah, actually, that is a good question. Actually, you should be able to initalize by calling latex#init(), although I realize that this won't work because the default settings are defined in the ftplugin. I will fix this later.

In the mean time, it is interesting for me if we could understand WHY the plugin does not get initialized. Could you try to add some echomsgs to the ftplugin file, that is, to ftplugin/tex.vim. In particular, I suspect that the ftplugin is not fully loaded, so that if you add an echo after line 13, it will not be displayed. I am curious if it is because of line 7 or line 10.

[lervag]

Changeset 89a47a0 moves default options to within latex#init(), which means that you should be able to manually load vim-latex if it wasn't loaded automatically by the ftplugin system.

[petobens]

Once again I'm probably not following you. I apologise for that. If the ftplugin/tex.vim from the latest commit looks like this:

if exists('g:latex_enabled') && !g:latex_enabled
  finish
endif
if exists('b:did_ftplugin')
   finish
endif
let b:did_ftplugin = 1
echomsg "Hello World"
call latex#init()

the echo message is not displayed when using my minimal vimrc and opening a tex file (such as foo.tex) for editing. Calling :echo latex#info() returns "vim-latex has not been initialized!".

If I try to initialize vim-latex manually (using once again my minimal vimrc) by running :call latex#init() from foo.tex file, then vim freezes.

Note once again that this doesn't affect my normal usage of the plugin. However I'm happy and willing to test any change that you desire to implement.

[lervag]

Could you change ftplugin/tex.vim like this:

if exists('g:latex_enabled') && !g:latex_enabled
  echomsg 'g:latex_enabled is either undefined or off!'
  finish
endif
if exists('b:did_ftplugin')
  echomsg "Already did ftplugin"
  finish
endif
let b:did_ftplugin = 1
echomsg "vim-latex is now enabled!"
call latex#init()

This should explain why vim-atex is not initialized. As I already mentioned above, I suspect the main problem is that you didn't add let g:latex_enabled = 1 to your minimal vimrc file.

However, it should have worked to manually initialize. Could the freeze be due to the get_main_recurse function? I just added a maxiter variable to prevent the while loop from being infinite.

[petobens]

I''ll test this shortly (I'm a bit busy right now). In the meantime I think there is a typo in the maxiter variable. Can you check it? I've added a note to your commit. Thanks

[petobens]

Changing ftplugin/tex.vim the way you suggest, makes vim return Already did ftplugin when opening a tex file.

With the maxiter variable (with the typo corrected) Vim doesn't freeze anymore and manual initialization works!

In general (not only in my vimrc), do I need to set

let g:latex_enabled = 1

?
In my full vimrc I haven't set that variable and vim-latex works fine.

[lervag]

I think I finally understand what is happening here. First, you do NOT need to set g:latex_enabled = 1 in your vimrc, as it should be enabled by default. However, what is happening is that the internal ftplugin for latex is loaded before vim-latex, and so the b:did_ftplugin variable gets set. This is because you do

set rtp += <some plugin>

Instead of

let &rtp = <some plugin> . &rtp

Regarding the maxiter: I don't like that hack! I tried a different implementation of the while loop now, which works well on linux/unix. I would be happy if you could test it again on windows, and in particular on the example we're discussing in this thread.

[petobens]

Thanks for the thorough explanation! The problem was indeed related to the way I was setting the rtp.

The new implementation of the while loop works perfectly on Windows!

Thanks for all the help and patience! I've have now switched full time to vim-latex. It is really awesome!

[lervag]

Great!

And thanks, I am very happy to hear that it works on windows and that you've made the switch. I'm also grateful for your input on how to improve the plugin! Keep it up! :)

[petobens]

Happy to help. Sorry that I didn't try the latexmk functionality on Windows but I don't use it myself (I use a tool call arara to compile my documents). However I'm willing to test any other functionality on Windows. Just let me know.

[lervag]

Great, I'll let you know! :)

[petobens]

Maybe this sentence in the docs can now be updated?

It also assumes that the main tex file lives in the same folder or the parent folder of the
current file.

[lervag]

Yes, indeed.

[petobens]

Excellent. Thanks