TOC window: Does not show all sections if some are folded in the tex file. about vimtex

[lervag]

Strange. I am not able to reproduce this issue. Could you make sure you do a full recompile after your previous issue?

Also: I found a different bug that I just fixed where there was not added a space before the custom g:latex_latexmk_options, so that in your example, you could get something like latexmk ... -pvc-xelatex, which obviously fails.

After getting the latest updates, could you test if you have the same problem again. Make sure to to a make clean, that is: <leader>lk, then <leader>lc, then <leader>ll (first stop any running latexmks, then do latexmk -c, then start latexmk again).

[nasenatmer]

Okay. pulled the changes, now \ll works again. However, the observed behaviour is still there:

I even moved main.tex .. so old files cannot be in issue at all. However, as it seems this is not of too much importance to any of us and as I won't have acceess to computers over the weekend this will have to wait for a bit. And who knows, maybe it again has something to do with some setting in my .vimrc. So after the weekend I'll try out with a vanilla .vimrc and report back.

[lervag]

Very strange. Are you sure LaTeX-Box is not also active? I almost suspect it is, since you never complained about the issue where compilation did not work with g:latex_latexmk_options.

You should also be aware that I have some informative features, such as <leader>li and <leader>lh. I don't think these are relevant here, but they are good to know about.

Could you change the names of the section in the main file, just to make sure that the TOC is made from the correct tex/aux file?

[lervag]

Just for you info: I tested the issue on a different laptop as well, and I am still not able to reproduce.

[nasenatmer]

Heyya,

• Yes, I rmed LaTeX-Box before setting up vim-latex, so that was not the case anymore
• I noted the g:latexmk_options issue in the last 2 lines of the top post, but in the meantime started xelatex from shell directly
• I went through the documentation and I like them (especially <leader>li, while <leader>lh is a bit longish) a lot!
• I killed all perl processes, moved the tex file to another folder and renamed the section, save the file, press <leader>ll and what I see is still (all done with reduced .vimrc and blank ftplugin/tex.vim file):
  
  and when I press j a few times:
  

But again, this is really not a big thing at all and not necessary to be fixed as long as you can't even reproduce it. Let's leave it at that and if somebody else gets this strange behaviour it might be more worthwhile to investigate into it, otherwise it might safely be assumed that it is somehow local to my machine and not a bug of vim-latex itself…

[lervag]

Just a couple of follow-ups:

1. I'm glad that you like the documentation. However, I'm curious what you mean about <leader>lh being a bit longish. That is, I can only understand that you mean the output of the command is too long. If so, then I admit that I agree. However, I am not sure how to make it better. If you have suggestions for improvements, please share!
2. It is a little bit annoying to not understand what is happening here. However, since I am not able to reproduce, I will leave the issue closed for now. If either you manage to understand what is happening and can provide more details, or if someone else reproduces the issue, then we reopen.

In the mean time, please feel free to open issues whenever you find something that could be/should be fixed or improved! :)

[nasenatmer]

Regarding the output of <leader>lh: I was thinking about that and thought about sorting the output in a special way but I haven't found the time yet to look into it and see whether that would make any difference, but rest assured that as soon as I'll have an idea, I'll come up with it! :)

[lervag]

Note that it is already grouped by map modes (n, v, and o), as seen in the function autoload/latex.vim:latex#help().

[nasenatmer]

Ah, that was not apparent at first, I was always looking at the functions only and I think this is why it seems a bit hard to decrypt as it prints out the pure functions and not translations of them. But I can also see the point of this behaviour, as then at least it is clear to people what the mappings map to…

[lervag]

Yes, exactly. And since all the functions are explained (at least somewhat) in the documentation, one should at least be able to get some help from this list of mappings.