Diagnostic Line Numbers are offset by one in certain situations

[hahuang65]

With file after/ftplugin/markdown.lua having the contents of

require("otter").activate({ "python" }, true, true, nil)

If I open nvim . and navigate to notebooks/notebook.ipynb to open it, otter will activate, and have the diagnostics offset by 1 line.

If I directly open nvim notebooks/notebook.ipynb, the code in after/ftplugin/markdown.lua will not trigger (not sure why), but calling require("otter").activate({ "python" }, true, true, nil) manually will cause diagnostics to appear on the correct line.

Similarly, if I don't have the after/ftplugin/markdown.lua, and manually activate otter, no matter how I open it, the offset issue does not exist.

Originally thought this was a molten issue, but after discussing in benlubas/molten-nvim#178 I've discovered it's more likely something in otter.nvim

[benlubas]

I'm able to reproduce this, will work on a minimal config, there are a lot of plugins at play here.

Specifically the issue is opening an ipynb file that's autoconverted to markdown it looks like.

[benlubas]

It looks like we write the otter buffer with line numbers off by one, and the original time that we grab diagnostics this isn't accounted for. I'm slightly confused on why it's only in this one situation though we don't normally write the otter buffer with line numbers off by one.

I'll note that the diagnostics do update correctly after writing the file or changing it to cause a diagnostic update in the otter buffer.

[hahuang65]

What's strange to me is... why does it happen when it's done quickly (via ftplugin/markdown.lua), but not when run manually after the file is opened.

I assume the operations are the same. Would it have something to do with the timing of Jupytext.nvim completing?

[jmbuhr]

Interesting. This is where jupytext sets the filetype, so it is when otter would kick in: https://github.com/GCBallesteros/jupytext.nvim/blob/6e439dc048986bcc00f8ba8695cb452de932127b/lua/jupytext/init.lua#L139

[benlubas]

https://github.com/GCBallesteros/jupytext.nvim/blob/6e439dc048986bcc00f8ba8695cb452de932127b/lua%2Fjupytext%2Finit.lua#L149

Lmao. This bug is as dumb as I thought it might be. Otter is doing nothing wrong here. I think they're deleting and not writing afterward so otter doesn't pick up the change (bc sync raft isn't called after this delete).

[benlubas]

Easy fix is rearranging the code in there so filetype is set after. I can open a PR in a little bit when I'm more awake.

[hahuang65]

I think they're deleting and not writing afterward so otter doesn't pick up the change (bc sync raft isn't called after this delete).

Good find! Sneaky downstream effects based on this small "hack".

[jmbuhr]

hm, technically this isn't even a bug then. Otter diagnostics get updated on write and it's up to the user do the writing or choose additional auto command events on which to do the updates (see otter config). Nonetheless it would of course be great if they changed it in the way proposed by Ben, but I would frame it as doing us a favor instead of fixing a bug or hack.

[benlubas]

Yup, definitely not a 'bug' more of an unfortunate side effect.

[benlubas]

@hahuang65 this should be resolved now if you update jupytext.nvim

[hahuang65]

@benlubas thanks so much. Verified that it's fixed.
Thanks for your help and patience thru this "bug" journey.