vimtex#init() not called

[sharethewisdom]

Describe the issue

Upon omni completion, various errors pop up, depending on my setup. In the test script below, it's
E121: Undefined variable: g:vimtex_complete_close_braces. The issue is that vimtex#init() is not called.

$ nvim --version
NVIM v0.4.0-887-g69b3d5acd
Build type: RelWithDebInfo
Features: +acl +iconv +tui
$ uname --kernel-release
5.1.12-arch1-1-ARCH

health#vimtex#check
========================================================================
## vimtex
  - OK: Vim version should have full support!
  - OK: General viewer should work properly!
  - WARNING: Compiler callbacks will not work!
    - ADVICE:
      - `neovim-remote` / `nvr` is required for callbacks to work with neovim
      - Please also set |g:vimtex_compiler_progname| = 'nvr'

Steps to reproduce

I keep the vimtex repo in ~/.local/share/nvim/site/pack/github/start, managed with minpac. Run the below script, and try omni completion.

#!/bin/sh
tmpdir=$(mktemp -d)
trap "rm -rf $tmpdir; exit 1" INT TERM
nvdir=${tmpdir}/nvim
pack=~/.local/share/nvim/site/pack/github/start
mkdir -p ${nvdir}/ftplugin
cat <<VIMRC > ${nvdir}/init.vim
set nocompatible
set runtimepath=/usr/share/nvim/runtime,${nvdir},${pack}/vimtex,${pack}/vimtex/after
filetype plugin indent on
syntax enable
packadd vimtex
VIMRC
cat <<FT > ${nvdir}/ftplugin/tex.vim
setl omnifunc=vimtex#complete#omnifunc
FT
cat <<FILE > ${nvdir}/file.tex
%! TEX root
\documentclass{myarticle}
\begin{document}
% type some tex command and complete with CTRL-X CTRL-O
% try :echo b:vimtex
\end{document}
FILE
nvim --noplugin --clean -n -u ${nvdir}/init.vim ${nvdir}/file.tex

I probably overlooked something...

[lervag]

The problem here is that for some reason, vimtex is not properly loaded. My guess is that it is because you are not loading it properly with the new pack system, but I am not sure.

Or, perhaps this is all intended, and your goal is to only use the omnicomplete function from vimtex and ignore everything else?

[lervag]

set runtimepath=/usr/share/nvim/runtime,${nvdir},${pack}/vimtex,${pack}/vimtex/after

Are you sure you should not put something of this in the packpath?

[sharethewisdom]

Thanks, I want most of vimtex's features though.

Vim finds the plugin, and I'm interested to know what a "properly loaded" plugin means. Vimtex appeared to be "properly loaded" until a while ago (using minpac). I also have no minpac issues with my other ftplugin's. Using runtime! plugin/**/*.vim and runtime! ftplugin/**/*.vim in stead of packadd is to no avail.

If I add the checks from ~/.local/share/nvim/site/pack/github/start/vimtex/ftplugin/tex.vim in ${nvdir}/init.vim with echomsg it returns three zero's as expected (which mean false in vimspeak). I'm already out of ideas here...

[lervag]

I've created test files similar to your script:

> tree
.
├── ftplugin
│   └── tex.vim
├── init.vim
├── minimal.tex
└── pack
    └── github
        └── start
            └── vimtex

With init.vim being

set nocompatible
set runtimepath+=.
filetype plugin indent on
syntax enable
packadd vimtex

If I start with nvim -u init.vim minimal.tex, I can first confirm that the ftplugin/tex.vim file has been sourced, which indicates that this should set up the runtimepath correctly to my cwd.

However, with the packadd vimtex, I get the error

E919: Directory not found in 'packpath': "pack/*/opt/vimtex"

As I have no experience with the packadd feature, I have to admit I don't quite understand why this is wrong. That is, I would expect the pack/*/start/vimtex to be loaded.

[andymass]

@lervag In this case, . should be added to packpath, not runtimepath. packadd vimtex a) adds the pack's directories to runtimepath and then b) sources the files

[lervag]

Huh, OK. I read :help packadd:

'packpath' 'pp'		string	(default: see 'runtimepath')
	Directories used to find packages.  See |packages|.

So I looked at :help runtimepath, and I noticed that pack/ would be searched for runtime files. This made me think it would be enough to alter runtimepath. I'm still a little bit confused...

[lervag]

When I add set packpath+=. I can finally reproduce this issue. That is, it seems that vimtex is properly loaded in the runtimepath, but the ftplugin was never executed.

[lervag]

I notice that packadd vimtex is not necessary since it is in the start path. It seems packadd makes no difference in this case.

[lervag]

Ok, so, some progress. When vimtex is loaded through the packadd system, it seems it is put after the internal ftplugin. This ftplugin sets b:did_ftplugin, which prevents vimtex from loading.

With the "old style" plugin managers, e.g. vimplug, :Plug 'lervag/vimtex' will ensure that the vimtex plugin is placed before the internal runtimepaths. And this clearly explains the present issue. I am not sure how to fix this.

I also noticed that packadd vimtex is necessary when I include silent edit minimal.tex in the init.vim file to ensure that vimtex is added to the runtimepath before loading the file.

[lervag]

Ok, now I'm far enough. The problem is as stated above: When vimtex is loaded with packadd or the packages feature, it will be placed in the wrong order in the runtimepath. The consequence is that the internal ftplugin/tex.vim plugin is loaded before vimtex and defines b:did_ftplugin, which will disable vimtex.

IMHO, this is not a vimtex issue. If you want to use vimtex, you should ensure that it is loaded before the /usr/share/vim/vim81/ftplugin/tex.vim (or similar on other systems), else all bets are off. Vimtex was not written to be compatible with the internal ftplugin.

My advice would be to open an issue with minpac. Perhaps something may be done on that end, or perhaps someone there knows a workaround.

[andymass]

It would be possible to add a function vimtex#pack_install() which moves the path to the start of rtp:

function! vimtex#pack_install() abort " {{{1
  if !exists('s:sfile')
    return
  endif
  let l:path = fnameescape(fnamemodify(s:sfile, ':h:h'))
  unlet s:sfile
  execute 'set rtp-=' . l:path
  execute 'set rtp^=' . l:path
endfunction

let s:sfile = expand('<sfile>')

" }}}1

Though the user would then have to do:

packadd! vimtex
call vimtex#pack_install()

or

au FileType tex ++once call vimtex#pack_install()

vimtex#pack_install() could also be called automatically in plugin/vimtex_pack.vim however this would apply for any installation method, unless we somehow check that the plugin was actually installed as a pack (maybe if <sfile> matches glob */pack/*/{opt,start}/*).

[lervag]

@andymass Thanks for the suggestion. I've mentioned this in the README file now with a link here for anyone who needs a solution.

[sharethewisdom]

thanks for the suggestions!

Though, I'd like to know your opinion on the (somewhat unrelated, and possibly edge-case) problem with a plugin's runtimepath in front of $VIMRUNTIME when expecting :help subject to give precedence to tags in $VIMRUNTIME, but ending up in plugin documentation. This actually happens to me more often than I can exemplify.

Should there be an after/doc directory to solve my small frustration? Should the "sophisticated algorithm" for :h {subject} be changed? Should plugin writers only use prefixed or otherwise unused tags? Or do you think prepending to $VIMRUNTIME is fine, and the user should move all doc/ directories to a path that's behind $VIMRUNTIME? Perhaps an overwriting ftplugin could somehow use a different check (like b:loaded_foo_did_ftplugin) so that it can be appended after $VIMRUNTIME?

ps: vim-packager also uses the pack feature

[lervag]

Though, I'd like to know your opinion on the (somewhat unrelated, and possibly edge-case) problem with a plugin's runtimepath in front of $VIMRUNTIME when expecting :help subject to give precedence to tags in $VIMRUNTIME, but ending up in plugin documentation. This actually happens to me more often than I can exemplify.

Should there be an after/doc directory to solve my small frustration? Should the "sophisticated algorithm" for :h {subject} be changed? Should plugin writers only use prefixed or otherwise unused tags? Or do you think prepending to $VIMRUNTIME is fine, and the user should move all doc/ directories to a path that's behind $VIMRUNTIME? Perhaps an overwriting ftplugin could somehow use a different check (like b:loaded_foo_did_ftplugin) so that it can be appended after $VIMRUNTIME?

I think you raise an interesting question here. Personally, I've tried to prepend vimtex to all help tags in the vimtex doc. I find that this generally works well, but I still sometimes experience the same issue as you mention. This does occur more often with other plugins, though. Still, I find it is not so bad. I usually use CTRL-d a lot to see possible completions for :h subject, and this often provides a clue to how I should spell the subject to find the proper help page.

I really don't think there is much hope in altering the behaviour of the vim plugin community, that is, I don't think plugin authors will start to move their docs to after/doc. Even though I do think that seems like a good idea, if it works (I guess it does, but I have not tested it).

In any case, it is helpful to read the :help online-help manual entry, since it does give a lot of useful hints for how to find the proper pages.

[leok610]

@andymass Can you please explain I would implement this? Where do I put this code block? How can I make sure it's called every time I run Vim? I have Vim 8.1 running with some plugins installed natively, but I'm not experienced in coding.

[andymass]

@leonorbert, @lervag Unfortunately that snippet has to go inside the file with vimtex#init so it isn't really something that can be used within a vimrc.

[sharethewisdom]

@leonorbert If you're fine with the "wrong" order of vimtex in the runtimepath, just call vimtex#init() in your ftplugin/tex.vim to get it working. You can use a custom buffer variable to prevent subsequent unnecessary calls.

if exists("b:did_user_ftplugin") | finish | endif
let b:did_user_ftplugin = 1
" If it's in opt/
packadd! vimtex
if get(g:, 'vimtex_enabled')
  call vimtex#init()
endif

[leok610]

Perhaps vimtex#init() isn't my issue: I tried removing the file $VIMRUNTIME\ftplugin\tex.vim entirely and vimtex still doesn't load.

I came to this thread because of the link in the README about the native installation method. The two other plugins I have in $HOME\vimfiles\pack\bundle\start load fine, and vimtex is there beside them. With this vimtex#init() error would I see vimtex in the runtimepath, but in the wrong place? It's not sourced in a runtime log I made:
novimtex-runtimelog.txt

Sorry if I'm missing something basic on installation methods. I did try Pathogen to install vimtex, but couldn't get that to work either. I'm running Vim 8.1.1986 on Windows 8.1.

[sharethewisdom]

I never used vim on windows. I don't think your ftplugin\tex.vim is being sourced: did you notice the forward slash in C:\Users\Norbert/vimfiles? Could you please doublecheck the runtimepath and the packpath?

[lervag]

@leonorbert Feel free to open a new issue if necessary; if so, please follow the issue template and provide all relevant context.

[leok610]

So it was something basic after all. Sorry! I got this working fine with the default installation method after reading through more of the Vim documentation on file types and plugins. You may want to alter the README page to give novices like me a way to test the installation of Vimtex. I didn't realize two things:

1. Vimtex only loads with .tex files
2. Help tags for packages have to be compiled manually (I was trying to test installation with a help search).

But at least I can say that the runtime paths are in the correct order with the default Vim package installation on Windows 8.1.

I'm happy to have this TeX working environment, thank you for all of your development work!

I'm still having an issues with window focus and forward/inverse search to SumatraPDF, similar to #680 and #1495. I'll experiment with it more and post on #1495 if I can't figure it out.

[lervag]

You may want to alter the README page to give novices like me a way to test the installation of Vimtex.

I don't mind altering, but I would much appreciate any concrete suggestions. To me it seems quite clear that Vimtex loads on .tex files, considering it is a filetype plugin. I do understand that there is a lot of stuff to learn/know about Vim in order to understand all these things, but I don't think I can add all of that in the README file.

Help tags for packages have to be compiled manually (I was trying to test installation with a help search).

Yes, but this is also quite clearly stated in all documentation. Also, today it is quite normal to use a plugin manager such as vim-plug, which should handle this automatically. Again, feel free to suggest a change to the README.

I'm happy to have this TeX working environment, thank you for all of your development work!

I'm happy to hear things work, and thanks for the feedback!

[leok610]

Well, my problem was not knowing about file type plugins, until I went through the Vim documentation more thoroughly. I found that and the helptags, but a pointer in the right direction would have saved me time. Vim has a lot of information to take in!

Since I was installing plugins for the first time, it seemed like a native installation method was simpler than a plugin manager. In case there are other novice users out there who come to your page, the following README additions might be helpful. I tried to keep the additions brief, and I don't know if you want those external links at the end or not.

More about this bug report

I could be misunderstanding the issues in this thread, but for me following the setup directions in h: packages allows Vim to load Vimtex fine. If the h: packages directory structure is followed, Vimtex and the other plugins in the ~\vimfiles\pack\*\start folder are put at the start of the runtimepath. The default packpath begins with the user plugins directory, so when Vim is started or a .tex file is opened, the user directories are added to the start of the runtimepath. So Vimtex runs first and overrides the default tex.vim file.

Even :packadd works for optional plugins in the default /opt directory. However, if it's a file type plugin, that file type can't be opened before :packadd is used.

I did reproduce this bug by using a custom/start directory. I added that directory to the packpath and then saw it at the end of the runtimepath. As a result vimtex did not load. After thinking about what it says in h: packages more, I may have a solution. @sharethewisdom, I was able to get vimtex to load from this directory by adding the packages path to the start of both the packpath and runtimepath in my vimrc.

Maybe you know how to use :redir already, but it was new to me (no surprise). This is what I did in my vimrc with the plugins stored in a test ~\Backup\pack\*\start path:

1. Ran :redir @j | set packpath? | redir END
2. Added this line to my vimrc using "jp to paste the default packpath:

set packpath=~/Backup,~/vimfiles . . . 

3. Ran :redir @j | set rtp? | redir END
4. Added the following line, removing all the paths at the end referring to packages:

set rtp=~/Backup,~/vimfiles . . . 

5. Closed the vimrc and restarted gVim with a .tex file. Vimtex loaded with it! The new runtimepath had ~/Backup/ followed by all of the ~/Backup/ plugin subdirectories, followed by ~/vimfiles/, followed by the the $VIMRUNTIME default directories.

(Because of Windows, I had to change all backslashes in the paths to forward slashes and escape the spaces with preceding backslashes. Otherwise Vim could not read the vimrc.)

If this works for other Vim setups, you could put something about it in the README, or maybe somewhere in the help documentation if it's too long.

Suggested README additions

Installation

If you use vim-plug, then add the
following line to your vimrc file:

Plug 'lervag/vimtex'

Or use some other plugin manager:

• vundle
• neobundle
• pathogen

If you use the new native package installation feature in Vim 8 (h: packages):

• Clone this repository to your $HOME/.vim/pack/*/start/ directory ($HOME\vimfiles\pack\*\start for Windows).

• For Vimtex helptags, you need to compile them with a line in your vimrc unless ALL is set. (see h: helptags).

• Please note that by default Vim puts custom /start/ plugin directories at the end of the runtimepath, causing Vimtex and other file type plugins not to load. See vimtex#init() not called #1413 for two suggested solutions.

• You can check for installation by looking for vimtex's directory in the runtimepath with :set rtp? after loading a .tex file. You can also execute :scriptnames to see that the vimtex scripts are loaded.

• See here and here for more about how to use Vim's native package installation.

[lervag]

Thanks for the writeup and suggested change to the README.

Personally, I don't really see why anyone really wants to use the native feature. Using vim-plug is very simple, it just works, and it makes it very easy to keep your plugins up-to-date. But that's just my opinion, of course.

[leok610]

You're welcome, I learned a lot by working through it. I'll try out vim-plug and see how it works.

FYI, you have one typo in your update, "ifletype " instead of "filetype." I don't know if you meant to disable the link to this thread, either.

Again, thanks for you all work on this plugin.

[lervag]

Thanks for noticing the typo and the missing link!

Again, thanks for you all work on this plugin.

My pleasure. I find it is a very nice hobby. It is fascinating how many different types of challenges there are in writing and maintaining a plugin like this.

[patashish704]

Hi,
Thanks for creating this great plugin. I only want to add that I have Vim 8.1 (patch1-2218) installed and use its native package feature. I had no problems loading and using vimtex with it. I use the opt folder under pack, and use packadd to load the vimtex plugin. In a repeat test, I also installed vimtex using the minpac package manager, and there weren't any issues there either. I verified that here vimtex loads before the builtin ft plugin.

There is something I noticed: if there is some delay between the g:vimtex_imaps_leader '`' and the character, the imaps characters won't expand. So the users should ensure that the leader and the characters are typed in quick succession.

[lervag]

Thanks for creating this great plugin

No problem, thanks for the kind words! :)

There is something I noticed

Yes, this is standard Vim behaviour. See :help timeout.

[zacmar]

Is there any update/clarification on this? I'm currently trying to migrate to the native plugin/packaging solution. My main motivation was to be able to use git submodules, which may also be possible with something like vim-plug, but its very unclear to me what exactly a :PlugUpdate would do in this situation. Hence I like the separation between managing the plugin code (i.e. which exact version/branch/etc of the plugin I want using git) and actually adding it to the vim runtime with packadd!. In my opinion this also makes it easier to deploy an existing vim configuration to new machines.
Anyway, currently vimtex resides in pack/bundle/opt, and I'm calling packadd! vimtex in my init.vim. As far as i can tell, everything is working as expected. With that, the information on in the readme seems inaccurate.
But i did some more experiments:

echo "packadd! vimtex" > minimal.vim
vim -u minimal.vim test.tex

^ This works perfectly fine, as far as i can tell.
On the other hand, when i run

vim -u NORC test.tex
:packadd! vimtex

vimtex does not load at all. What is going on here exactly, and what is the preferred way of installing vimtex when using the native packages feature?
Edit: Also, if the problem is that g:did_ftplugin is true after the internal ftplugin was run, wouldn't that be easy to fix by letting vimtex maintain it's internal "was run" variable? Or does vimtex simply not work when the internal ftplugin was already run?

[lervag]

Vimtex needs to be properly loaded before you open a tex file. That is, your runtimepath must include vimtex so that the filetype plugin is detected. This explains why your second example does not work. packadd essentially sets your runtimepath.

The proper way of adding vimtex with the package feature, as far as I understand, is to add it to some path that loads vimtex on vim startup. With "load", I only mean that the runtimepath must include vimtex. You should ensure vimtex is available inside your packpath under a pack/../start directory. It should not go under pack/.../opt, because this requires you to manually load vimtex. Read the docs here: :help packages.

[zacmar]

Yes, I think I understand now. Essentially having things in pack/.../opt and calling packadd! in init.vim/.vimrc is equivalent to having things in pack/.../start. So the only thing that's (unfortunately) not possible right now is to have vimtex in pack/.../opt and calling packadd! vimtex in $userruntime/ftplugin/tex.vim. Although, since I'm not a plugin developer, I'm not sure how much of an impact this actually has, assuming that the plugin is properly written (autoload?).
Still, I dont understand this part of the readme:

Please note that by default Vim puts custom /start/ plugin directories at the end of the runtimepath, causing Vimtex and other file type plugins not to load. See #1413 for two suggested solutions.

This seems to be inaccurate, since vimtex does in fact load without any workarounds when putting it either in pack/.../start or pack/.../opt and calling packadd! vimtex soon enough (e.g. in the .vimrc).

Also, now that I think about it, simply having everything in opt and loading it eagerly anyways emulates how most people would use their traditional plugin manager, where "disabling" a plugin is done by simply commenting out the corresponding line. Kind of also raises the question whether vimtex would work if loaded with, e.g.

Plug 'lervag/vimtex', { 'for': 'tex' }

[lervag]

So the only thing that's (unfortunately) not possible right now is to have vimtex in pack/.../opt and calling packadd! vimtex in $userruntime/ftplugin/tex.vim.

Why unfortunately? There is no reason to do this. The point of ftplugin is to load the plugin when the filetype is detected, so vimtex will not do anything unless necessary. There should be no effect on startup time.

I don't use the package feature myself, and so the docs/readme may be somewhat inprecise, sorry. Feel free to suggest an update!

Plug 'lervag/vimtex', { 'for': 'tex' }

This is again unecessary for the same reasons. But it should work, I think; not sure.

[sharethewisdom]

Just to follow-up, Greg Hurrell mentioned the ftdetect caveat with packadd! just three weeks before I opened this issue. 🙄

[clason]

@lervag I've recently started using (neo)vim's native package feature (using the new https://github.com/wbthomason/packer.nvim). I have it put vimtex into the /start/ directory, and put the configuration (especially of the toc feature, which requires vimtex#init() to have been called) into /nvim/plugin config directory. I have not noticed any issues so far, so either this problem is solved now, or I'm missing something?
scriptnames shows

[...]
 13: ~/.config/nvim/plugin/vimtex.vim
[...]
 43: ~/.local/share/nvim/site/pack/packer/start/vimtex/ftplugin/tex.vim
[...]
 95: /usr/local/share/nvim/runtime/ftplugin/tex.vim
 96: ~/.local/share/nvim/site/pack/packer/start/vimtex/after/ftplugin/tex.vim
 97: ~/.local/share/nvim/site/pack/packer/start/vimtex/indent/tex.vim
 98: /usr/local/share/nvim/runtime/indent/tex.vim
 99: ~/.config/nvim/syntax/tex.vim
100: /usr/local/share/nvim/runtime/syntax/tex.vim
101: ~/.local/share/nvim/site/pack/packer/start/vimtex/after/syntax/tex.vim
[...]

[lervag]

Thanks, interesting to know. Was not aware about packer.nvim.

[andymass]

@clason do you know what packer.nvim is actually doing on the "use {plugin}" command? Maybe it adjusts the runtimepath?

[clason]

@andymass It does not; that is handled by the underlying native package mechanism; this is a major difference to vim-plug. (I learned that the hard way...)

use only tells packer to manage that plugin: where to get it from, where to put it. You can also specify whether (and if so, how) to lazy-load it, but then you need to call packer.compile() to generate a vimscript loader (that calls packadd appropriately) which you need to put somewhere in rtp.

[sheerun]

I think the best solution would be for vimtex to use vimtex filetype instead of tex. It would prevent native vim files to be loaded at all times. Similar issue: sheerun/vim-polyglot#580

[lervag]

I think the best solution would be for vimtex to use vimtex filetype instead of tex. It would prevent native vim files to be loaded at all times. Similar issue: sheerun/vim-polyglot#580

Why is that? Why does vim-polyglot bundle the the plugin by Benji Fisher, presumably the same script that ships with Vim by default? IMHO, vimtex should not do anything; instead, vim-polyglot should simply remove the tex scripts.

If there continues to be a conflict here, then I might consider to add a check for vim-polyglot and add a warning to users that use vim-polyglot to disable the latex part.

[lervag]

Ok, this issue is now discussed at #1822. I'm therefore locking this thread.