Closed xfzv closed 1 week ago
does this happen on stable? nvim v0.10?
icon_preset = "diamond"
is working perfectly fine for me. Could you elaborate on what you mean by "isn't working"
I'm having the same issue. I just upgraded to the latest tag, and now I get an error every time NeoVim loads.
Failed to run `config` for neorg
/usr/share/nvim/runtime/lua/vim/re.lua:150: attempt to perform arithmetic on local 'item' (a userdata value)
# stacktrace:
- /usr/share/nvim/runtime/lua/vim/re.lua:150
- vim/_init_packages.lua:0 _in_ **__index**
- /neorg/lua/neorg/modules/core/tempus/module.lua:18
- /neorg/lua/neorg/core/modules.lua:442 _in_ **load_module**
- /neorg/lua/neorg/core/modules.lua:337 _in_ **load_module**
- /neorg/lua/neorg/core/modules.lua:337 _in_ **load_module**
- /neorg/lua/neorg/init.lua:100 _in_ **org_file_entered**
- /neorg/lua/neorg/init.lua:45 _in_ **setup**
- ~/.config/neorg/init.lua:46 _in_ **config**
- ~/.config/neorg/init.lua:23
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1716656478
I found the minimum config to trigger it is just loading core.ui.calendar
. With just that submodule in the kickstart config, I get the error.
I went through the commits history, the error is gone after downgrading to c659b0901bea4143667489ee2af4c78762fabc5c and occurs again when pinning to the next commit (52a37e01abe059c6431f744eab9f22626fb275c5).
does this happen on stable? nvim v0.10?
Yes it does with 0.10 too on my Gentoo system:
% nvim -v
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.0-beta3
But it doesn't on my Arch Linux system:
% nvim -v
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1720049189
icon_preset = "diamond"
is working perfectly fine for me. Could you elaborate on what you mean by "isn't working"
*
character is displayed instead of diamond for headings:
The diamonds are sometimes showing up after closing the error but it's random and takes several tries.
The actual source of this issue stems from the Neovim source from what I can tell. In Neorg's code we only compile a single pattern, nothing remotely complex or hacky. I'll have to debug this further.
@vhyrro unless you're seeing this, it seems it's a problem with the version of luajit that their neovim is complied with.
LuaJIT 2.1.0-beta3
vs. 2.1.1713484068
@Reyu that's a different problem that was already fixed
FWIW, dev-lang/luajit-2.1.1716656478
has been stabilized on Gentoo but the issue persists after updating (with both Neovim 0.10 and Git):
% nvim -v
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1716656478
% nvim -v
NVIM v0.11.0-dev-449+gc7b0334ce-dirty
Build type: Release
LuaJIT 2.1.1716656478
@Reyu that's a different problem that was already fixed
@benlubas I'll open a a separate issue if it is not the same, but I can assure you that it's not fixed. Latest stable Neovim and Neorg is giving me this error.
@Reyu I'm not sure what I read earlier, that does look like the same issue, my bad.
I'll add that I'm unable to reproduce with the same nvim version by loading only the calendar module (I can't reproduce this at all though)
@benlubas No worries, I've misread things at work only to start an uneeded fuss at work more times than I can count. Can hardly blame someone for similar in an open source project. Heh
I am on Gentoo, as well, if I can help try and diagnose anything. It seems to be a common factor, so far.
@Reyu does downgrading to https://github.com/nvim-neorg/neorg/commit/c659b0901bea4143667489ee2af4c78762fabc5c also solve the issue on your end?
I mean, the error is caused by loading the regex runtime file it looks like. So reverting to a commit that doesn't use vim.re.compile will cause the issue to go away.
Could either of you try to source a file that only contains: vim.re.compile("")
?
Run nvim --clean
and then source that. or this will probably do the trick: nvim --clean -c "= vim.re.compile"
None of those should error, but I suspect they will for you.
Indeed:
% nvim --clean -c "= vim.re.compile"
Error detected while processing command line:
E5108: Error executing lua /usr/share/nvim/runtime/lua/vim/re.lua:150: attempt to perform arithmetic on local 'item' (a userdata value)
stack traceback:
/usr/share/nvim/runtime/lua/vim/re.lua:150: in main chunk
[C]: in function 'require'
vim/_init_packages.lua: in function '__index'
[string ":lua"]:1: in main chunk
Press ENTER or type command to continue
Edit: same error when sourcing manually after running nvim --clean
.
seems like Gentoo's nvim package is just broken then. My best guess is that it's shipping with the wrong version of lpeg somehow
You can actually go into /usr/share/nvim/runtime/lua/vim/re.lua
and add a vim.print(m)
on line 12 to see if it looks right. Specifically make sure the version
field is "LPeg 1.1.0"
dev-lua/lpeg
is still at 1.0.2 on Gentoo whereas Arch has 1.1.0
% nvim --clean -c "= vim.re.compile"
{
B = <function 1>,
C = <function 2>,
Carg = <function 3>,
Cb = <function 4>,
Cc = <function 5>,
Cf = <function 6>,
Cg = <function 7>,
Cmt = <function 8>,
Cp = <function 9>,
Cs = <function 10>,
Ct = <function 11>,
P = <function 12>,
R = <function 13>,
S = <function 14>,
V = <function 15>,
locale = <function 16>,
match = <function 17>,
pcode = <function 18>,
ptree = <function 19>,
setmaxstack = <function 20>,
type = <function 21>,
version = <function 22>
}
Error detected while processing command line:
E5108: Error executing lua /usr/share/nvim/runtime/lua/vim/re.lua:151: attempt to perform arithmetic on local 'item' (a userdata value)
stack traceback:
/usr/share/nvim/runtime/lua/vim/re.lua:151: in main chunk
[C]: in function 'require'
vim/_init_packages.lua: in function '__index'
[string ":lua"]:1: in main chunk
Press ENTER or type command to continue
Edit: on Arch:
% nvim --clean -c "= vim.re.compile"
{
B = <function 1>,
C = <function 2>,
Carg = <function 3>,
Cb = <function 4>,
Cc = <function 5>,
Cf = <function 6>,
Cg = <function 7>,
Cmt = <function 8>,
Cp = <function 9>,
Cs = <function 10>,
Ct = <function 11>,
P = <function 12>,
R = <function 13>,
S = <function 14>,
V = <function 15>,
locale = <function 16>,
match = <function 17>,
pcode = <function 18>,
ptree = <function 19>,
setmaxstack = <function 20>,
type = <function 21>,
utfR = <function 22>,
version = "LPeg 1.1.0"
}
<function 1>
Press ENTER or type command to continue
Oof, that potentially sounds like the reason. Since Neorg uses luarocks I guess we could require our own version of lpeg instead, but I'd rather try to fix this on Neovim's side (which is the root cause). Maybe Neovim should refuse to build with older versions of lpeg?
Came back to this after work, and after reading through everything I bumped the version of lpeg up in an overlay and reinstalled it. With lpeg-1.1.0, there are no errors at startup, and I can actually use the calendar functions. Need to get Gentoo to add the new version, but that's not a problem for here, I think.
Can confirm the error is gone for me too after updating dev-lua/lpeg
to 1.1.0 in a local repository:
% eix -cI dev-lua/lpeg
[I] dev-lua/lpeg (1.1.0[1]@07/17/2024): Parsing Expression Grammars for Lua
[1] "xfzv" /var/db/repos/xfzv
I'm having the same issue. I just upgraded to the latest tag, and now I get an error every time NeoVim loads.
Failed to run `config` for neorg /usr/share/nvim/runtime/lua/vim/re.lua:150: attempt to perform arithmetic on local 'item' (a userdata value) # stacktrace: - /usr/share/nvim/runtime/lua/vim/re.lua:150 - vim/_init_packages.lua:0 _in_ **__index** - /neorg/lua/neorg/modules/core/tempus/module.lua:18 ...
Same here on my fedora 40 system.
~ ❱ nvim -v
NVIM v0.10.0
Build type: RelWithDebInfo
LuaJIT 2.1.1713773202
Maybe it makes sense to take the calender out of core.defaults
again (temporarily)?
Same here on my fedora 40 system.
Will be fixed soon:
koji wait-repo f40-build-side-92914 && fedpkg build --target=f40-build-side-92914
Waiting ...
Fedora 40 Update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1b0f0b9cdc
This issue can be resolved by upgrading neovim to the latest stable release v0.10.1.
Quick fix for Fedora users who don't want to wait for the release:
# upgrade neovim from the testing repo
sudo dnf install neovim --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1b0f0b9cdc
This issue can be resolved by upgrading neovim to the latest stable release v0.10.1.
@dmonad I'm using Neovim nightly and the issue persists if using dev-lua/lpeg-1.0.2-r101::gentoo
instead of 1.1.0.
% nvim --version
NVIM v0.11.0-dev-495+g807eb4434-dirty
Build type: Release
LuaJIT 2.1.1716656478
nightly is not officially supported by neorg. But if it works for you by upgrading lpeg
that's good I guess.
On fedora, I'm now using lua-lpeg 1.0.2-13.fc40
and nvim v.10.1
and I don't encounter the issue anymore.
NVIM v0.10.1
Build type: RelWithDebInfo
LuaJIT 2.1.1713773202
Run "nvim -V1 -v" for more info
The issue is not fixed by updating neovim to version 0.10.1, it is fixed by updating lua-lpeg to version 1.1.0.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1b0f0b9cdc includes lua-lpeg 1.1.0!
I'm sure you have lua5.1-lpeg 1.1.0 installed because the neovim 0.10.1 package requires it!
$ grep lpeg neovim.spec
Requires: lua5.1-lpeg >= 1.1.0
BuildRequires: lua5.1-lpeg >= 1.1.0
The issue is not fixed by updating neovim to version 0.10.1, it is fixed by updating lua-lpeg to version 1.1.0.
Right, sorry. I used the wrong command to query the package version.. :sweat:
I suffer from the same issue on Gentoo. The wiki suggests, that its possible to disable loading of specific modules: https://github.com/nvim-neorg/neorg/wiki/Defaults
It does not seem to work though. How could I mask tempus
and ui-calendar
for the time being without just deleting them from the lua/modules/defaults/module.lua
file? (not nice for long term updates)
@JonasToth I'd just use dev-lua/lpeg-1.1.0
ebuild in a local repository for the time being if I were you. A bug was opened last month to get 1.1.0 on official Gentoo repositories but it hasn't been updated since then.
See this article on the Gentoo Wiki. It's even easier if you use app-eselect/eselect-repository.
Or just use bob ツ https://github.com/MordechaiHadad/bob
I'm going to close this b/c it's not an issue with neorg. It's an upstream problem with gentoo.
If anyone needs this on gentoo, here the version of my overlay https://github.com/JonasToth/jonas-overlay/tree/master/dev-lua/lpeg
(the previous source code location had certificate issues)
Upstream gentoo should be fixed now. Can others please verify this too?
Works for me too!
Prerequisites
Neovim Version
NVIM v0.11.0-dev-434+ga0fd51c1e-dirty
Neorg setup
Actual behavior
After updating Neovim (Git) to https://github.com/neovim/neovim/commit/a0fd51c1e2db17ab21e2a2c907b232d05dfffc88, the following is printed when opening a
norg
file:Plus,
isn't working anymore.
It used to work just fine yesterday so I guess this is due to a recent Neovim commit (2024-07-16).
Expected behavior
No error is printed
Steps to reproduce
.norg
file with the setup abovePotentially conflicting plugins
No response
Other information
No response
Help
None
Implementation help
No response