-
-
Notifications
You must be signed in to change notification settings - Fork 218
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
E1502: Lua failed to grow stack to 4001 #1044
Comments
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. |
@georgeharker Thanks for chiming in. However, I have installed the same neovim version on cli 0.9.5 where I cannot reproduce the issue
Opening the tex file is fine:
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. |
Ah that is interesting will take a look |
@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: |
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). |
I do not think this issue is related to the used package manager (packer or lazy).
Thanks for the confirmation.
I do not think that an outdated package or tree-sitter grammar is the reason.
This is what I cannot confirm. I am using vimtex for several years and neovim for about 2 years as my daily editor.
One can install diferrent neovim versions with
Maybe I do this. The author of vimtex is always very helpful even though he is on Linux and not macOS.
VimTeX defines classic syntax highlighting groups and is vital for some of its functionality and recommends to disable treesitter for tex files.
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" },
},
...
I guess I have to debug it better to see from where these errors come. |
Sorry for the noise and confusion in this issue.
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.
/Users/kiryph/.local/share/bob/v0.9.5/nvim-macos/bin/nvim Following is outdated, since the issue remains:
|
Ok great. I’m so glad there’s a workaround. We can grab a new neovim version when we next release. |
I tried it on a fresh new day and unfortunately, the issue persists. I am not sure what was different to the last time I tried it. I guess it has to be figured out what the error actually throws. |
I get this warning every time I navigate to a memory-intensive buffer such as a large file or the NERDTree split, both when using the builtin neovim and the Homebrew neovim binary. |
It was my understanding that our build is now vanilla neovim but perhaps we should explicitly set a larger stack size if it is not. |
Stumbled across here from Google. I also seem to get this error a ton if NERDTree is open. I don't use VimTeX. |
I'm running into this regularly. I do use NERDTree and always have it open. I tried using the CLI version of VIM instead of the version shipped with vimR but same issue regardless (albeit seems to take more minutes before it shows up whereas it's usually within a minute with the builtin nvim). Using system NVIM (
Using builtin NVIM:
|
To be clear above, I have not seen this issue when running neovim directly in a terminal console - only when running through vimR with various neovim binaries selected. |
I'm also getting this regularly, it's getting quite frustrating as I have to restart my editor randomly or this makes me basically unable to work. Any ideas on how we can set the stack size higher? To confirm what @mmerickel is saying I do not get this is normal neovim only vimr Furthermore this seems to cause a hang when quitting if you ignore it too long Mac Debug ReportDate/Time: 2024-03-18 14:21:27.734 -0700 End time: 2024-03-18 14:21:39.169 -0700 OS Version: macOS 12.5.1 (Build 21G83) Architecture: arm64e Report Version: 35.1 Incident Identifier: BF81EA4F-317E-4DA3-9FE8-63A102103783Data Source: Stackshots Command: VimR Event: hang Hardware model: MacBookPro18,4 Time Awake Since Boot: 170563s Fan speed: 0 rpm Timeline format: stacks are sorted chronologically
|
Has anyone found a combination of older versions of nvim or vimr that stops this? I can't take it anymore. I'd love to keep using vimr but I am going to switch editors soon. |
Anecdotally the error has disappeared for me since I switched to nvim-tree so in my little world of plugins nerdtree feels like it was the primary culprit. Would love to see whatever setting vimr is using be configurable or higher or whatever is required to avoid it occurring though since obviously it never occurred for me via the cli. |
I went to the releases page, scrolled down a bit, landed on VimR-v0.43.0.tar.bz2 for no reason in particular, and switched to that. Things seem to be working for me now (fingers crossed), nerdtree and all. I'll try @mmerickel's approach at some point. |
Never mind, that stopped it for like one day. |
i've found that downgrading to version 0.44.0 stops this problem. although, it seems that sometimes the at this point i just have an unzipped version of |
As others have mentioned in this thread, the problem goes away when I either
|
When I open a larger tex file in VimR (version 4.46.0), I get following error:
I do not get the error in VimR version 0.44.0 with neovim 0.8.2 from January 2023.
I use the ftplugin VimTeX.
I raise this issue in the repository of VimR since I do not get the error on the command line or with other neovim guis such as neovim-qt or neovide.
Steps to reproduce:
~/.local/share/nvim/lazy/vimtex/test/test-toc-speed/main.tex
VimR version: 0.46.0 (20240102.233758)
The text was updated successfully, but these errors were encountered: