Commit 1b2f39dc1ee82b0 is introducing error "Value for option 'undolevels' is out of range"

[andrewferrier]

Since commit 1b2f39dc1ee82b0, I see this error: "Value for option 'undolevels' is out of range".

Recreation instructions:

• Open NeoVim
• Open any file
• Press - to go up
• Before dirbuf opens, see this error:

E5108: Error executing lua ...e/nvim/site/pack/packer/start/dirbuf.nvim/lua/dirbuf.lua:51: Value for option 'undolevels' is out of range
stack traceback:
        [C]: in function 'nvim_buf_set_option'
        ...e/nvim/site/pack/packer/start/dirbuf.nvim/lua/dirbuf.lua:51: in function 'fill_dirbuf'
        ...e/nvim/site/pack/packer/start/dirbuf.nvim/lua/dirbuf.lua:127: in function 'init_dirbuf'
        ...e/nvim/site/pack/packer/start/dirbuf.nvim/lua/dirbuf.lua:184: in function 'open'
        [string ":lua"]:1: in main chunk

For what it's worth, my undolevels option is set to 1000 (I like lots of undo ;)

Reverting to commit bec06dcb9095 fixes the problem.

(By the way I like the index number vs. hash - although are collisions really likely? I would have thought it was more likely someone might accidentally increment an index with Ctrl-A and cause dirbuf to get confused ;). But I digress...)

[andrewferrier]

Not sure if it's related, but I also get an error now when in an (unmodified) Dirbuf buffer - if I press on any file, I see an error: "Cannot enter 'qf.lua'. Dirbuf must be saved first" (where qf.lua is the filename I'm trying to open). I have not modified the Dirbuf buffer.

It is related - if I revert to bec06dc that issue goes away too.

[andrewferrier]

Actually, turns out I'm not setting my undolevels - it's 1000 by default.

[andrewferrier]

FWIW, if I run lua print(vim.api.nvim_buf_get_option(0, 'undolevels')) from my Vim instance, I get 4469498752. Which is obviously a crazy number. I wonder if the buffer-specific get_option doesn't work correctly when it's using a global default.

Anyway, gotta dash... hope that helps for now.

[elihunter173]

Thank you for the detailed bug report! I'm gonna run through this quickly because hopefully it's an easy fix and not a bug in Neovim.

It sounds like vim.api.nvim_buf_get_option(0, 'undolevels') returning 4469498752 is the underlying problem because when I manually call vim.api.nvim_buf_set_option(0, "undolevels", 4469498752), I get the exact error you get "Value for option 'undolevels' is out of range".

Not sure if it's related, but I also get an error now when in an (unmodified) Dirbuf buffer

This is related. The error occurs before Dirbuf gets a chance to set modified to false

(By the way I like the index number vs. hash - although are collisions really likely? I would have thought it was more likely someone might accidentally increment an index with Ctrl-A and cause dirbuf to get confused ;). But I digress...)

I thought collisions wouldn't happen too! That's why I chose hashes instead of indexes initially. In fact, I had this exact comment before the check for colliding hashes

-- This should never happen

But alas it happened in #20 and I decided that Dirbuf working is better even if it means having this minor sharp edge.

[elihunter173]

I think I've tracked down the issue. From :help 'undolevels'

The local value is set to -123456 when the global value is to be used.

I suspect then that Neovim is trying to return -123456 but mangling the value into 4469498752.

[elihunter173]

Ah. It's not being mangled but is returning uninitialized garbage (https://github.com/neovim/neovim/pull/15996)

nvim_{buf,win}_get_option return the local value of an option if set. If the local value is unset then they throw an error for string-type options and return an uninitialized garbage value for number options (see https://github.com/neovim/neovim/issues/15587)

What a footgun. Apparently I've been experiencing this bug too but on all of my machines the uninitialized garbage just happens to be in range

[elihunter173]

@andrewferrier Please test out the undolevels-hack branch. I think it should fix the issue. It seems to have for me

[lourenci]

Yep. It has been fixed for me too.

[elihunter173]

Sweet! I'll take a +1. The fix has been merged to main

[andrewferrier]

Thanks! Sorry I didn't get to this in time to test. Works for me too.

[elihunter173]

No worries! You were plenty fast enough. I just wanted to merge the fix once I heard it was affecting more people :+1: