opening references picker causes telescope error

[avonmoll]

Error executing vim.schedule lua callback: .../cal/share/nvim/rocks/rocks_rtp/lua/telescope/pickers.lua:1467: Cursor position outside buffer
stack traceback:
    [C]: in function 'nvim_win_set_cursor'
    ...cal/share/nvim/rocks/rocks_rtp/lua/telescope/pickers.lua:1467: in function ''
    vim/_editor.lua: in function <vim/_editor.lua:0>

The telescope overlay opens and the error is repeated after every keypress. Telescope seems to be working fine for everything else other than papis.nvim. I tried the latest release of Telescope (0.1.6) and got the same error (although it pointed to line 1345 instead of 1467).

[jghauser]

Did this just randomly start happening? What is your setup (OS, neovim version, package manager, etc.)? I'm on NixOs unstable using the latest stable neovim version, and everything seems to be working fine here.

[avonmoll]

OS: macOS 12.7.4
neovim: v0.10.0-dev-2849
neovim package manager: rocks.nvim

I just noticed that the error only shows up when the list of results is greater than 500. For example, my main papis library has 668 documents in it, so for the first few characters the error pops up with every keypress. Then, once it's below 500, there are no more errors.

[jghauser]

ok, i don't have a mac, but i'll see if i can replicate the problem with the neovim dev version and rocks.nvim in a container (it might take a few days though, i'm pretty busy atm). have you by any chance recently moved to rocks.nvim and the problems started then? also, just to be sure, the above is the entirety of the error message, right?

[avonmoll]

Yes to both (I recently moved to rocks.nvim from packer.nvim and that is the entirety of the message). It's hard to say whether the issue started when moving to rocks.nvim because it'd been a while since I'd opened the picker. It's entirely possible that this issue is rocks-induced (or otherwise due to my configs).

[jghauser]

Great, thanks! I'll have a look and see what I find. Let me know if you figure out anything else. In any case, it would be nice for papis.nvim to work with rocks.nvim and neovim 0.10 as both are likely to see a lot more adoption very soon :).

[avonmoll]

FYI, I also tested out using lazy.nvim and have the same issue (with telescope.nvim 0.1.6).

[jghauser]

I just realised that the reason I'm not getting this error is because I have set sorting_strategy = "ascending" in my telescope settings and the line that causes the error is only active when the strategy is descending. I still don't have any idea why this error occurs, but I'm putting this here as a quick workaround.

The relevant lines (mostly for future reference):

https://github.com/nvim-telescope/telescope.nvim/blob/f12b15e1b3a33524eb06a1ae7bc852fb1fd92197/lua/telescope/pickers.lua#L1469-L1475

[jghauser]

So, the problem seems to be with \n that have somehow snuck into info.yaml files. So, the error here isn't really with papis.nvim, but with problematic info.yamls. I've opened an issue at Papis (see above) to catch these with papis doctor. I might add a string cleaner to papis.nvim, though this really should be solved elsewhere. For now, you can find problematic files by running the following command in your library dir:

find . -name 'info.yaml' -exec grep -lP '(?<=.)\\n(?=.)' {} \;

In each of the files this outputs, look for stray \n. The one that caused the error for me was in a title, but there are likely to be other elsewhere too (at least there were for me). I'm gonna close this issue now. If you run into any trouble still, please do re-open!

EDIT: I figured why not clean the strings and implemented this in 31304b0e123cb059bfc803f5b3bc5b9f53142f8b.

[avonmoll]

Thanks for digging into this. I believe I eliminated all of the instances of \n in my info.yaml files. My version of grep does not have the P flag, so I used ripgrep via rg "[^a-zA-Z\s/\d(:\.>{\"\[\-;]r" which caught all of the \ns (among other things as well). I still am having the same error when opening the picker. I wonder if there are other escape codes that could be causing the issue.

[jghauser]

What a shame, and there I thought I had fixed it! :sweat: Can you try the branch in #73 and see if this fixes it? There, I've added a line that (I think) should remove all control characters from strings when importing info.yamls. Make sure to run :PapisReInitData after switching to the branch.

If it doesn't fix it, we might have to bisect the library to figure out what's causing the issue (this is how I finally caught the issues with \n).

[avonmoll]

I indeed went the bisection route and found the single offending info.yaml that remained. It did not have a literal \n but it had multiple line breaks in the title. It was something like:

title: 'Some title: plus some subtitle

that was somewhat long'

Edit: I have not tried the branch in #73 yet, so I'm not sure if that branch catches this particular kind of issue. Edit2: I should have clearly mentioned that I'm now error-free. Thank you for your help!

[jghauser]

Oh great! I've never come across such multiple linebreaks (which is why I said over at papis/papis that I didn't think those cause issues). I can definitely see that this would cause issues. From a quick check it looks like my fix in #73 fixes it, though I think this is really a problem with Papis (which shouldn't be creating such info.yaml files). Thanks again for the report!