Vimtex using Lazy.nvim causes problems with detecting the structure of the text inside a .tex file.

[JxJxxJxJ]

Description

Hello, I use LunarVim and recently there has been an update that switched from using Packer to Lazy as plugin managers. This seemed to cause problems with vimtex (as explained here, vimtex is not meant to be lazyloaded, but I'm not certain that such is the case right now).

The current problem I'm encountering is this, it's very hard to replicate (it's very inconsistent) but happens enough times to be really hard to work on .tex files. So for example with a simple align* enviroment. This should be used inside text and not in mathmode, so

\begin{align*}
  a_{11} x_1 +  \dots + a_{{1n} }x_{n}   &=  b_1  \\
   \vdots  &=  \\
   a_{m1}  x_1  +  \dots  + a_{{mn}} x_{n}  &= b_{m} 
\end{align*}

But the inconsistencies are that, if I just copy and paste it, chances are that the text is not understood properly as that it should be in mathmode

But it's inconsistent, for example if I put $ $ around the enviroment (which is wrong) to trigger the text to be inside mathmode and then remove it I have this, which is more correct

The problem of discerning text from mathmode I believe happens mostly inside inline math

Here the text inside \text { } should be white, as it happens when it is inside displaymath.

I'm not 100% sure that the Vimtex + Lazy combo is causing the problem, so this issue is more to ask you where to start with debugging this (if that's not the case).

Steps to reproduce

No response

Expected behavior

No response

Actual behavior

No response

Do you use a latexmkrc file?

No

VimtexInfo

System info:
  OS: Linux 6.2.12-arch1-1
  Vim version: NVIM v0.9.0
  Has clientserver: true
  Servername: /run/user/1000/lvim.166525.0

VimTeX project: algebra
  base: algebra.tex
  root: /home/jx/Escritorio/notas-latex/algebra
  tex: /home/jx/Escritorio/notas-latex/algebra/algebra.tex
  main parser: fallback current file
  document class: report
  packages: algorithm2e amsbsy amsfonts amsgen amsmath amsopn amssymb amstext amsthm array atbegshi atbegshi-ltx atveryend atveryend-ltx auxhook babel bigintcalc bitset bookmark calc cancel catchfile centernot color comment enumitem environ epstopdf-base eso-pic etexcmds etoolbox expl3 fancyvrb float framed fvextra geometry gettitlestring graphics graphicx hycolor hyperref ifluatex ifmtarg ifoddpage ifplatform iftex ifthen ifvtex import infwarerr inputenc intcalc keyval kvdefinekeys kvoptions kvsetkeys l3keys2e letltxmacro lineno listings listingsutf8 lscape lstmisc ltxcmds mathtools mhsetup minted mleftright multicol nameref newpxmath pdfcol pdfescape pdflscape pdflscape-nometadata pdfpages pdftexcmds pgf pgfcomp-version-0-65 pgfcomp-version-1-18 pgfcore pgffor pgfkeys pgfmath pgfrcs pgfsys refcount relsize rerunfilecheck setspace shellesc stringenc tcolorbox textcomp theoremref tikz tikz-cd tikzfill-common tikzfill.image tikzsymbols titletoc transparent transparent-nometadata trig trimspaces uniquecounter upquote url varwidth verbatim xcolor xfrac xifthen xkeyval xparse xspace xstring xtemplate
  compiler: latexmk
    engine: -pdf
    options:
      -shell-escape
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
    job: 
      jobid: 33
      output: /tmp/lvim.jx/RTEXTT/0
      cmd: max_print_line=2000 latexmk -shell-escape -synctex=1 -interaction=nonstopmode -pdf -pvc -view=none -e '$compiling_cmd = ($compiling_cmd ? $compiling_cmd . " ; " : "") . "echo vimtex_compiler_callback_compiling"' -e '$success_cmd = ($success_cmd ? $success_cmd . " ; " : "") . "echo vimtex_compiler_callback_success"' -e '$failure_cmd = ($failure_cmd ? $failure_cmd . " ; " : "") . "echo vimtex_compiler_callback_failure"' 'algebra.tex'
      pid: 176173
  viewer: Zathura
    xwin id: 0
    cmd_start: zathura  -x "/usr/bin/nvim --headless -c \"VimtexInverseSearch %{line} '%{input}'\"" --synctex-forward 2729:1:'/home/jx/Escritorio/notas-latex/algebra/algebra.tex' 'algebra.pdf'&
  qf method: LaTeX logfile

[JxJxxJxJ]

This is problematic for example paired with the usage of snippets. Since it's just not "the color white/blue" what is annoying, but rather that the understanding of inside-which enviroment I am is wrong. If I am wrongfully inside bluetext, I trigger the in_mathzone conditions, and vice versa. I use the following functions to use as conditions with LuaSnips if it helps:

local in_mathzone = function()
  return vim.fn["vimtex#syntax#in_mathzone"]() == 1
end

local in_comment = function()
  return vim.fn["vimtex#syntax#in_comment"]() == 1
end

local in_text = function()
  return not in_mathzone() and not in_comment()
end

[JxJxxJxJ]

Also, I'm loading Vimtex the following way in Lazy.nvim

{
    "lervag/vimtex",
    config = function()
      vim.cmd("call vimtex#init()")
    end,
  },

If I were not to do the vim.cmd part, vimtex would not start after opening a .tex file. So there's another problem

[JxJxxJxJ]

A little video of me triggering this, I think it'll help to understand the issue

[lervag]

Hello, I use LunarVim and recently there has been an update that switched from using Packer to Lazy as plugin managers. This seemed to cause problems with vimtex (as explained here, vimtex is not meant to be lazyloaded, but I'm not certain that such is the case right now).

You can easily check if VimTeX is lazily loaded with Lazy. Simply do :Lazy and inspect the output. There will be many sections; the top section is "Loaded" which shows which plugins are loaded. This should contain VimTeX. If it does not, then VimTeX is lazily loaded.

The current problem I'm encountering is this, …

When I look at the little video you posted, I get a feeling that you are not actually using VimTeX for syntax highlighting. I may be wrong, but it is easy to check: Open a LaTeX file, move to the $ in some inline math expression and do :Inspect. Copy the output here.

Also, I'm loading Vimtex the following way in Lazy.nvim

Ah, no, this is very wrong! The config block is not relevant for VimTeX and you should never call the vimtex#init() function yourself unless you really know what you are doing. You should do this:

{
  "lervag/vimtex",
  init = function()
    vim.g.vimtex_options = "go here"
  end,
},

I assume you are setting your VimTeX options elsewhere; you should move them to the init block as indicated above.

If I were not to do the vim.cmd part, vimtex would not start after opening a .tex file. So there's another problem

Well, that's not good. As mentioned above, that part is very wrong. You should update as I've explained then report back.

[JxJxxJxJ]

It's very hard to debug this since I need to work on latex documents and I went back to using Packer with Lvim and Nvim 0.8.3. The "bad solution" was proposed in this github issue https://github.com/LunarVim/LunarVim/issues/3723

[lervag]

I've added a comment in the issue thread you mentioned.

[lervag]

I'm closing this issue, as it seems it should be resolved through https://github.com/LunarVim/LunarVim/issues/3723.

[albertfgu]

I saw this issue and was wondering what the correct way of configuring vimtex is using lazy.nvim but not LunarVim (more specifically I'm using LazyVim). Thus far I just loaded lervag/vimtex with no additional lazy.nvim options, and set the options inside nvim/ftplugin/tex.lua instead. Should I move them into an init option as suggested?

[lervag]

I saw this issue and was wondering what the correct way of configuring vimtex is using lazy.nvim …, and set the options inside nvim/ftplugin/tex.lua instead. Should I move them into an init option as suggested?

Yes, I think that is better.

Setting the options in your personal ~/.config/nvim/ftplugin/tex.lua (or …/tex.vim) should also work, since this file should be loaded before VimTeX is loaded. The load order is the important part, because VimTeX relies on user options being defined before initialization.

Specifying the VimTeX configuration in the init option for lazy.nvim will always work. Notice that setting a few variables do not impact the startuptime (basically it is much less than 1 ms), so there is no point in lazy loading that part anyway.

[lervag]

It seems LunarVim just merged a PR that should fix this issue: https://github.com/LunarVim/LunarVim/pull/4124.

[JxJxxJxJ]

Thank you so much for your help

[lervag]

My pleasure, glad to se this is resolved! :)