More flexible system for finding documents associated with an entry

[tmalsburg]

The idea is to have a set of functions for finding documents associated with a bibliographic entry:

• Find documents following the scheme BibTeX-key.[pdf|djvu|docx|...].
• Find documents referenced in the file field.
• Find documents following other schemes that may ocurr in the wild.

The user can then specify a list (e.g. bibtex-completion-document-detection-functions) of any subset of these functions that might yield useful results for their bibliography. Helm/ivy-bibtex will use the functions in this list sequentially until either a document is found (stop early) or until all documents are found for an entry (exhaustive search). This system is more flexible than what we have now because it allows mixing and matching of schemes and it gives users an easy way to add functions for their own custom naming schemes. By default all functions would be included in the list, so helm/ivy-bibtex would find documents using all known reference schemes. However, since finding documents can be slow for large bibliographies, the user would typically remove all methods that are not relevant for their bibliography.

[mgttlinger]

Other issues that should be fixed/considered by this:

• [ ] #63
• [ ] #88
• [ ] #90
• [ ] #95 ?
• [ ] #100
• [ ] #135
• [ ] #187
• [ ] #209
• [ ] #254
• [ ] #271 ?

[tmalsburg]

Thank you! You are right that notes are similar in some ways. But I think we can disregard them for now. The two ways to do notes (single file, multiple files) seem to work for the vast majority of users. But at a later time we may consider using the same or a similar approach for notes as for documents.

[mgttlinger]

Well similar to #254 I'm not one user of this vast majority because I would like my notes and my documents to have the same (different than default) name.

So my idea would be to think about splitting the path and the name generation so that the search/storage paths for notes can be different for the notes while the names can be reused. The difficulty with that is obviously that when searching for things it is not an issue to have many options (apart from performance with excessive libraries) while when we create a new note having options is rather bad because we might pick the wrong one.

I like the per project approach mentioned in #271 because at least in my use case I have one bibtex file with one corresponding storage tree and one corresponding location for notes (and possibly one naming scheme of things).