rafaqz
commented
4 years ago Basically Unite.vim is doing a string match on the whole string entries you see in the Unite split. The closest match will be returned. This plugin is actually not involved in that, except for making the list of entries for Unite.
If your reference keys are truly unique strings it will always work. It may not work if some keys are subsets of other keys that come first in the list. Normally I use autherYEARTitle and find it very hard to ever have two keys where one is a subset of the other. But I guess it's possible to happen if they have very similar named papers in the same year, like smith2010In and smith2010Inside, where co on smith2020In could return either one depending on which comes first.
You could improve it by using something like we use to do the fulltext search command and doing an exact search internally, but I haven't tried that and will never have time to.
I would say try to pick a more unique key style and redo your betterbibtex database, but it will kill all of your old papers...
Other keys following a different rule may be the problem too, it's hard to say.
Djoop
Hi and thanks for the plugin. I mainly use it to open papers from the reference key, using the "co" shortcut, which works well most of the time. However, it happens sometimes that the paper which is opened is not the one corresponding to the citation. It is, however, often another paper from the same author. I'm not sure what is the exact criterion to reproduce this. Should it be expected due to the "hacking" nature of the plugin, or is it a bug? Is there an implicit requirement on the citation keys to get this functionality to work properly (I use betterbibtex for the keys, but I also have order keys which follow a different rule, could it be the cause of the problem?)