Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vimtex does not load properly #566

Open
1 task done
isaacST08 opened this issue Jan 18, 2025 · 5 comments
Open
1 task done

Vimtex does not load properly #566

isaacST08 opened this issue Jan 18, 2025 · 5 comments
Labels
bug Something isn't working

Comments

@isaacST08
Copy link

⚠️ Please verify that this bug has NOT been reported before.

  • I checked all existing issues and didn't find a similar issue

Description

When adding the vimtex plugin either in vim.lazy or vim.extraPlugins it does not load the commands related to Vimtex.

From what I can find this is because the default ftplugin runs before Vimtex's ftplugin and then Vimtex never gets loaded.

👟 Reproduction steps

add the following to your nvf config:

      vim.lazy.plugins.vimtex = {
        enabled = true;
        package = pkgs.vimPlugins.vimtex;
        lazy = false;
        setupOpts = {
          init = ''
            vim.g.vimtex_view_method = "general"
            vim.g.vimtex_view_general_viewer = "okular"
            vim.g.vimtex_compiler_method = "latexrun"
          '';
        };
      };

👀 Expected behavior

Vimtex works.
Commands such as VimtexCompile work.

😓 Actual Behavior

The only command that is loaded is VimtexInverseSearch. But this command also fails.

The docs are loaded correctly so :help vimtex works.

But the rest of the commands do not work.

💻 Metadata

  • system: "x86_64-linux" - host os: Linux 6.12.9, NixOS, 24.11 (Vicuna), 24.11.20250115.e24b4c0 - multi-user?: yes - sandbox: yes - version: nix-env (Nix) 2.24.11 - channels(root): "nixos-24.05" - nixpkgs: /nix/store/awsvw44jla0idziiks2zwgzslfd2dczn-source

📝 Relevant log output

None
@isaacST08 isaacST08 added the bug Something isn't working label Jan 18, 2025
@isaacST08
Copy link
Author

For anyone else who has this issue, I've found a hack workaround:

For the plugin add the following to your nvf config:
(There are notes indicating where it has changed compared to the initial report)

      lazy.plugins.vimtex = {
        enabled = true;
        package = pkgs.vimPlugins.vimtex;
        lazy = true; # Changed this
        ft = "tex"; # Added this
        setupOpts = {
          init = ''
            vim.g.vimtex_view_method = "general"
            vim.g.vimtex_view_general_viewer = "okular"
            vim.g.vimtex_compiler_method = "latexrun"
          '';
        };
        # Added this
        after = ''
          vim.api.nvim_command('unlet b:did_ftplugin')
          vim.api.nvim_command('call vimtex#init()')
        '';
      };

Adding the after = '' ... '' block makes it so that when the plugin is loaded it will pretend that ftplugin has not happened yet and then will (re?) initialize vimtex. (I tried this with a before and only the unlet command but it only had the same result as the original issue.)

Adding lazy = true; means that the after block will not happen when all the other plugins are being loaded. I don't know if this will break things but I added it just to be safe (safer*).

Adding the ft = "tex" line means that the plugin is only loaded on tex files. I did this to again avoid loading with all the other plugins and since tex files are the only ones I need this plugin for it might possibly allow me to avoid this hack breaking other plugins or functionallity. If there are other file types which need this plugin you can just add them following the nvf appendix B.

Again, this is a hack. I don't know what else uses the b:did_ftplugin and what unsetting it might do/break but for now this seems to work well enough until a better fix can be found.

@NotAShelf
Copy link
Owner

I don't believe nvf sets anything that would conflict with vimtex loading. CC @horriblename regarding the plugin loader. If you're open to it, a PR for the appendix with a minor addition to the docs for other users dealing with vimtex would be appreciated. Alternatively, a module addition could also be considered if you're willing to get it in.

P.S. I no longer use any kind of Tex tooling thanks to the wonders of Typst and Pandoc. #525 might be a better addition than Vimtex, which seems to be mostly in Vimscript- which we are trying to avoid for performance reasons.

@horriblename
Copy link
Collaborator

horriblename commented Jan 18, 2025

seems like an oversight on mnw's part, mnw put plugins after nvim's builtin ones in rtp, so nvim builtins get priority over the plugin. I'll investigate in a couple of days

@isaacST08
Copy link
Author

I created a pull request #569 with what I got done today.

I was using texlab for the LSP but I didn't know it could compile so thank you for that info. I used vimtex before I migrated over to nvf so I just tried to use that until you mentioned the capabilities of texlab.

My implementation uses Texlab as the LSP, and compiles using Texlab via tectonic as the default (but that can be changed to whatever the user wants) and you were definitely right: it runs so much faster than what vimtex was able to.

It also uses okular as the default for previewing the compiled document but that can also be changed to the user's preferences.

horriblename added a commit to horriblename/mnw that referenced this issue Jan 23, 2025
some plugins (e.g. vimtex) rely on being before
nvim builtins in rtp
(NotAShelf/nvf#566)
horriblename added a commit to horriblename/mnw that referenced this issue Jan 23, 2025
some plugins (e.g. vimtex) rely on being before
nvim builtins in rtp
(NotAShelf/nvf#566)
@horriblename
Copy link
Collaborator

@isaacST08 could you test the PR on mnw? just override mnw like this:

inputs = {
  mnw.url = "github:horriblename/mnw/prepend-rtp;
  nvf.url = "...";
  nvf.inputs.mnw.follows = "mnw";
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants