ml_get: invalid lnum: <num> // How to debug?

[richin13]

Hello 👋🏼

I'm a bit desperate with an error that keeps popping-up, I've narrowed down and the culprit is using the winbar feature:

function M.setup()
  ...
  local WinBars = {
    provider = "dummy"
  }
  require("heirline").setup(StatusLines, WinBars) -- This fails
  require("heirline").setup(StatusLines) -- This is fine
end

It happens every time and after different actions although I managed to fully replicated with coc's jump to definition functionality. The first screenshot was simply when trying to open the help pages for something and the error won't go away until I scroll all the way to the bottom and press enter. I'm pretty lost on what could be going on, my hunch is that a recent commit in upstream neovim messed something with this plugin so I'm curious if you're experienced something similar lately? Also, if you could point out to potential ways of debugging this I'd greatly appreciate it 🙏🏼

Env info:

• OS: GNU/Linux (Ubuntu 22.04) (Also happens in Arch Linux fwiw)
• Heirline HEAD: 805a158
• Neovim --version:

Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/cmake.config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az243-825

Features: +acl +iconv +tui
See ":help feature-compile"

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

[richin13]

Ok I found the exact commit where the bug was introduced in neovim: 9879fd5d087cc3939f91f4714b0f95f03a78c011 (diff)

[garymjr]

Hey @richin13, I also had this issue and I found that changing winbar to use vim.opt instead of vim.opt_local fixes the issue for me.

local function setup_local_winbar_with_autocmd()
    local augrp_id = vim.api.nvim_create_augroup("Heirline_init_winbar", { clear = true })
    vim.api.nvim_create_autocmd({"VimEnter", "BufWinEnter"}, {
        callback = function()
            -- change vim.opt_local to vim.opt
            vim.opt.winbar = "%{%v:lua.require'heirline'.eval_winbar()%}"
            vim.api.nvim_exec_autocmds('User', {pattern = 'HeirlineInitWinbar', modeline = false})
        end,
        group = augrp_id,
        desc = "Heirline: set window-local winbar",
    })
end

[richin13]

Thank you @garymjr, it did solve the issue for me too 🎉

[rebelot]

Unfortunately this is not a solution, as it voids the feature of not displaying the winbar on specific buffers. If the devs are not willing to endorse the hackish mechanism by which heirline achieves this (which is my guess) I'll have to change this mechanism but this will probably introduce some breaking changes

[joehannes]

@rebelot this not-solution worked for me as well after trying to fix this issue various plugins seem to be having (Neogit, Diffview, ...).

One hint as of my debugging endeavours: it seems conditions.buffer_matches has a bug, which actually would resolve the issue without using the other solution if it worked properly I guess. I haven't dug in your code, but this might help you:

• both Neogit and Diffview are having this problem in my case
• both plugins try to (as of my cfg) open a new Tab and display their stuff there in a new Window/Buffer

Behaviour:

1. Error is thrown right away, blocking the UI.
2. After unblocking the UI the new Tab/Window/Buffer is shown and heirline doesn't show a winbar

Hints/Clues:

• If I open Neogit before having opened any buffer in a blank neovim, the error doesn't occur and everything works
• if I print/debug in the WinBar-condition and print the filetype of the current file ... it gets me the last edited buffers filetype (the heirline.lua cfg buffer I guess) instead of the empty filetype or NeogitStatus filetype

=> this makes me think there might be a bug in conditions.buffer_matches ...

• triggered too soon (before the tabnew thingy is focussed by neovim itself??)
• having some kind of trouble with tabs
• the file matched against anyways, seems to be the last edited buffer instead of the new buffer in the new tab/window, as in my case, matching it against { filetype: { "lua" } } ... resolved the error (but of course that's no solution - I was just editing a lua file before opening NeogitStatus) ...

well, anyways, I'm kinda stuck the regular/official way ... please have a look

[rebelot]

@joehannes this is hardly a heirline issue. And there's no workaround at the moment except using global winbar. Try for yourself:

nvim --clean
:setlocal winbar=foo
# write a few lines and move the cursor  away from first line
:help this

see https://github.com/neovim/neovim/issues/19458

[rebelot]

temporary fix:

require("heirline").setup(StatusLines)--, WinBar)
require("heirline").winbar = require("heirline.statusline"):new(WinBar)
vim.opt.winbar = "%{%v:lua.require'heirline'.eval_winbar()%}"

this will setup global statusline instead of a local one until this is fixed

[max397574]

should be fixed now (see linked issue) @rebelot