returning actual filename with completion-notes-template

[brianmcgillion]

HI,

I am using Mendeley to manage a bibliography and corresponding pdfs. in the .bib Mendeley and Zotero can add the file: item. However, as mentioned in the documentation for helm-bibtex, they use various formats :filename:pdf ...

I have the following template defined to insert the filename into NOTER_DOCUMENT though the same would apply for interleave.

(setq bibtex-completion-notes-template-multiple-files
      "${title} : (${=key=})

- tags ::
- keywords :: ${keywords}

\n* ${title}\n  :PROPERTIES:\n  :Custom_ID: ${=key=}\n  :URL: ${url}\n  :AUTHOR: ${author-or-editor}\n  :NOTER_DOCUMENT: /${file}\n  :NOTER_PAGE: \n  :END:\n\n")

In order to retrieve the filename I have hooked (read, copied the entire function to my init.el) bibtex-completion-apa-get-value

And added a line to split the filename stored in Mendeley/Zotero format and return it:

             ("year" (or value
                               (car (split-string (bibtex-completion-get-value "date" entry "") "-"))))
             **("file" (nth 1 (s-split ":" value)))**
             (_ value))

This is obviously a filthy solution. is there a way to specify I have a file in Mendeley format, return me the real filename for the template if it exists? Or to change the template to accept a call back function that the caller could use to format the fields before insertion into the notes file.

Any pointers would be great. Thanks

[tmalsburg]

Good point. There is one thing that makes this slightly non-trivial: An entry can have multiple PDFs associated with it. How shall we fill the template in this case?

[brianmcgillion]

I assume that the documents, if multiple, will be full, abridged etc. So the correlation of the noter notes will have to be specific to each document as headings etc could be added / missing from different versions. In this case, it could not be assumed which notes go with which pdf, so a separate bibtex entry would be needed if different notes were to be needed. In this case, would returning the first file in the list be a sensible option?

[tmalsburg]

There are many use cases for having multiple documents associated with just one bib entry. For instance, conference abstract plus poster, or conference abstract plus slides, or main paper plus supplementary infos, ... In all those cases I wouldn't want to have a separate entry for each PDF. There is also no guarantee that the first PDF will be the main document. So just linking to the first PDF may in your case, but I think there will be many users for whom this is not a desirable solution, myself included.

I think we may also approaching the underlying issue from an less-than-ideal angle. What you want is a convenient way to open the PDF while reading the notes, right? Having a link is one way to solve this but it's actually a bit clumsy. An alternative that works now is to place point on the BibTeX key (which I assume is part of your notes template) and to fire up helm-bibtex followed by M-n to select the thing at point. Then you have the entry and just need to press enter to open the PDF. Easy! If that's too many key presses, we could also write a function that opens the PDF(s) of the current entry directly (by collecting the BibTeX key from the properties drawer or wherever.) We already have something like that for .bib files. When you place the cursor on a bib entry and start helm-bibtex, it will preselect the entry under point.

[brianmcgillion]

Would providing a hook work in this case? bibtex-completion would generate the list of files. If there is a hook registered allow the caller to interactively select which file to use for their case and if there is no hook enabled or registered just return the comma/colon-separated list of files.

[brianmcgillion]

I have not tested if the same "%(org-roam-bibtex-process-file-field "${=key=}")" sexp method would work for straight helm-bibtex?

https://github.com/Zaeph/org-roam-bibtex/issues/4#issuecomment-614367122

But I have a working way to retrieve the filename. So I will close this off.

[tmalsburg]

This doesn't work with current helm-bibtex but we're working to improve note-taking and it may soon be possible. Glad you found a solution for your use case.

[tmalsburg]

We now have expansion of org-capture variables. I think this covers inline eval?