E1502: Lua failed to grow stack to 4001 about vimr HOT 21 CLOSED

It’s probably a neovim issue but you can point your vimr at the command line version you’re using in advanced prefs to check if that’s the case.

from vimr.

@georgeharker Thanks for chiming in.

However, I have installed the same neovim version on cli 0.9.5 where I cannot reproduce the issue

❯ nvim --version
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1692716794

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Run :checkhealth for more info
(base)

Opening the tex file is fine:

❯ nvim  ~/.local/share/nvim/lazy/vimtex/test/test-toc-speed/main.tex

Also pointing to the nvim binary installed from https://github.com/neovim/neovim/releases/tag/v0.9.5 for macOS does not remove the issue.

from vimr.

Ah that is interesting will take a look

from vimr.

@georgeharker Thanks for taking a look. Could you at least reproduce it?

When I install VimR version v0.44.0 with neovim 0.8.2 from January 2023, I do not get the error:

from vimr.

I don't use Lazy.nvim but installed via packer and see the same thing.

I also see the same with an external nvim but have zero idea why. Tried TSUpdate, Packerupdate to see if something was out of sync. I don't have an earlier neovim to hand to test if it's a neovim issue - but strongly suspect it's that or an incompatibility with vimtex and neovim version.

I also saw errors saying tree sitter was doing the highlighting - perhaps worth asking over at vimtex, or seeing if you can try a local neovim at an earlier version to validate if if's neovim at issue (we just invoke a neovim binary that we bundle, so I'm doubtful anything in the vimR code base would be causing this, it's probably just something in neovim / vimtex compatibility which I don't understand).

from vimr.

I don't use Lazy.nvim but installed via packer and see the same thing.

I do not think this issue is related to the used package manager (packer or lazy).

I also see the same with an external nvim but have zero idea why.

Thanks for the confirmation.

Tried TSUpdate, Packerupdate to see if something was out of sync.

I do not think that an outdated package or tree-sitter grammar is the reason.

but strongly suspect it's that or an incompatibility with vimtex and neovim version.

This is what I cannot confirm. I am using vimtex for several years and neovim for about 2 years as my daily editor.

This issue only occurs in the new VimR release with any neovim version. I have tried so far neovim versions 0.9.5, 0.9.0, 0.8.3, 0.8.2 (Update: versions 0.8.x are not compatible with VimR 0.46.0, no issue with 0.9.5 when pointing correctly to the binary):

I don't have an earlier neovim to hand to test if it's a neovim issue

One can install diferrent neovim versions with bob.

perhaps worth asking over at vimtex,

Maybe I do this. The author of vimtex is always very helpful even though he is on Linux and not macOS.

I also saw errors saying tree sitter was doing the highlighting

VimTeX defines classic syntax highlighting groups and is vital for some of its functionality and recommends to disable treesitter for tex files.

Thus, for people who use Tree-sitter, it is strongly advised to disable
Tree-sitter highlighting for LaTeX buffers. This can be done with the
ignore_install option for the setup part of nvim-treesitter, e.g.: >lua

Full FAQ entry can be found here.

Hence my tree sitter config is:

vim.defer_fn(function()
  require('nvim-treesitter.configs').setup {
    -- Add languages to be installed here that you want installed for treesitter
    ensure_installed = { 'c', 'cpp', 'go', 'lua', 'python', 'rust', 'tsx',
      'javascript', 'typescript', 'vimdoc', 'vim', 'bash' },

    -- Autoinstall languages that are not installed. Defaults to false (but you can change for yourself!)
    auto_install = false,

    highlight = {
      enable = true,
      disable = { "tex" },
    },
...

or seeing if you can try a local neovim at an earlier version to validate if if's neovim at issue (we just invoke a neovim binary that we bundle, so I'm doubtful anything in the vimR code base would be causing this, it's probably just something in neovim / vimtex compatibility which I don't understand).

I guess I have to debug it better to see from where these errors come.

from vimr.

Sorry for the noise and confusion in this issue.

1. Version 0.8.x are not compatible with the new VimR release. So I could not test them at all.

I did not first notice that in VimR configuration dialog tilde expansion for home directory does not work.

Maybe an error could be thrown if the entered path to a binary points to a non-existing file.

2. I could resolve the issue by correctly pointing to a manual installation of neovim 0.9.5

/Users/kiryph/.local/share/bob/v0.9.5/nvim-macos/bin/nvim

So the issue might be related to the nvim binary included in VimR.

Nevertheless I close this issue since I have a solution for me.

from vimr.

Ok great. I’m so glad there’s a workaround. We can grab a new neovim version when we next release.

from vimr.