bibtex-ls and associated commands not working, but fzf.vim integration is working as expected

[claman]

I was experiencing the same issue with both the CLI tools and within vim, but then specified the cache directory in my .vimrc and resolved the problem -- but only inside vim.

Trying to run bibtex-ls or the other commands as listed in the readme does launch fzf, but with no input. Trying to run bibtex-ls with the -cache option results in an error because there is no .lock file. How do I generate one? Or is there another configuration option that I've missed?

[msprev]

Not sure what is going on here, so a minimal working example would help. If you are on the CLI (e.g. bash) with a small, simple .bib file called test.bib, and you type:

bibtex-ls test.bib

You should see a printout of the full list of items in that file, nicely formatted (you might then pipe this list to fzf).

By default, bibtex-ls uses the system tmp directory for storing a cache. You can force this cache to be elsewhere by using the -cache option (typically something you'd want to do in vim/neovim which make their own assumptions about where to store temporary files). If you type:

bibtex-ls -cache=. test.bib

Should give you the same printout, and you will find 2 cache files stored in the current directory (which you can delete if you don't plan to keep calling bibtex-ls with them there).

Let me know how you get on with both of those tests.

[claman]

Sorry for not including a small test earlier! Pulling in 3 citations and running bibtex-ls test.bib works as expected, as does the caching option.

Here's the working test.bib:

@incollection{Skoie2012corpTib,
        author = {Skoie, Mathilde},
        booktitle = {{A Companion to Roman Love Elegy}},
        date-added = {2023-07-16 08:29:42 +0300},
        date-modified = {2023-07-16 15:13:20 +0300},
        editor = {Barbara K. Gold},
        location = {Malden, MA},
        pages = {86-100},
        publisher = {Blackwell Publishing},
        title = {\emph{Corpus Tibullianum}, Book 3},
        year = {2012}}

@article{SullivanHickel2023poverty,
        author = {Dylan Sullivan and Jason Hickel},
        date-added = {2023-06-30 12:48:31 +0300},
        date-modified = {2023-07-01 18:42:59 +0300},
        doi = {10.1016/j.worlddev.2022.106026},
        journaltitle = {World Development},
        pages = {1-18},
        title = {Capitalism and extreme poverty: A global analysis of real wages, human height, and mortality since the long 16th century},
        volume = {161},
        year = {2023}}

@article{DaltonEtAl2023nile,
        author = {Matthew Dalton and Neal Spencer and Mark G. Macklin and Jamie C. Woodward and Philippa Ryan},
        date-added = {2023-06-30 12:48:30 +0300},
        date-modified = {2023-07-01 18:47:19 +0300},
        journaltitle = {Geoarchaeology},
        pages = {1-23},
        title = {Three thousand years of river channel engineering in the Nile Valley},
        year = {2023}}

The thing that's confusing me is that running bibtex-ls on my full .bib file (1000+ citations) just hangs -- I've had the process running for the last few minutes without any apparent progress or changes -- but pulling that same file up in vim using \c works quickly and as expected.

[msprev]

That is a bit strange. It must be a parsing error with your larger bib file. There must something different about the error handling of your CLI vs vim that explains the difference in behaviour. Easiest way to find the issue is to progressively bisect the bib file (i.e. run it on first 500 entries, then 2nd 500 entries, then on the 250 entries that generate issues, etc.). Run the CLI on each one until you find the entry or entries that are causing it to choke.

An alternative way of tackling the problem is to run bibtool directly on your file as it has excellent error reporting on ill formed entries: https://github.com/msprev/fzf-bibtex#errors

[claman]

It turns out the running bibtool directly on the file did the trick! I had two entries listed with entry type collection and changing those to the book type fixedthe problem. I'm not entirely sure why since the bibtool lists that as an officially supported type. It might have something to do with the capitalization in my file vs. what the program is trying to parse...regardless, I'm glad that I've resolved the issue. Thank you for the help!