tmalsburg/helm-bibtex

Dynamic bibtex-completion-library-path

Opened this issue · 4 comments

Hello again! :)
Currently bibtex-completion-library-path gets a list of directories. Users can write a function that generates this list based on their need. However, (I think) in many cases, the result of this function can change based on what happens outside Emacs. For example, a user might want to include all pdf files within a directory and all of its subdirectories, except inside hidden folders and git repositories.

Currently, if a directory in bibtex-completion-library-path is deleted and no longer exists, we get an error. If a directory is added, then clearly the library will have no way of knowing this change (except by running the function again to set the value of bibtex-completion-library-path).

A solution for that is to allow bibtex-completion-library-path to get a list of directories and functions and then have a function like this:

(defun bibtex-completion-library-path ()
  "Evaluate the functions in the variable `bibtex-completion-library-path',
if there are any, and return a list of directories."
  (-flatten
   (mapcar
    (lambda (item)
      (if (stringp item)
          item
        (funcall item)))
    (-flatten bibtex-completion-library-path))))

Note that this change is completely backward compatible and doesn't break any existing setup.
I've implemented this in my setup and I'll be happy to make a pull request if this is something you'd like to implement.

I think you can simply use Emacs' function advising infrastructure to set bibtex-completion-library-path dynamically before running helm-bibtex or ivy-bibtex. I'd say that this is a natural/idiomatic solution and it doesn't require any changes in bibtex-completion.

Absolutely! Anyone who wants to use their pdf library from outside emacs and might have a different folder structure can just advice helm-bibtex, helm-bibtex-follow and ivy-bibtex.
This issue is mostly about official support in the package, since currently it feels like a hack.
I thought it might be best to raise it so that it's also considered when thinking about a comprehensive solution to #287.

This issue is mostly about official support in the package, since currently it feels like a hack.

It works and bibtex-completion (its caching mechanism) was designed with uses like this in mind. So I'd say, there's no reason to view this as a hack. Perhaps we can make it feel less hacky by officially endorsing this solution in README.org?

Sure, including it in README would be great! I can make a pull request describing how to do it if you want.

What I meant was that the advising mechanism itself is basically a hack! From the manual:
"... advice should be reserved for the cases where you cannot modify a function’s behavior in any other way. ... If you are writing code for release, for others to use, try to avoid including advice in it. ..."