Opening notes associated to .pdf with org-roam-bibtex

I use org-roam-bibtex together with a helm-bibtex interface, and a master .bib file generated by Zotero. I’m able to comfortably create an Emacs frame, launch helm-bibtex and then select a paper I want to read.

Using the Fn keys, I can select whether I want to view the .pdf of the paper, or open the .org note file associated with it – and if there are no notes, I am lead to an org-roam-capture template that creates a new notes file for me. From the notes file, I can invoke org-noter to view both the.pdf file and add notes to the note file at the same time.

I would like to do something slightly different now. I typically use helm-bibtex to open the .pdf file of the reference directly, using pdf-tools. I browse the file, and add highlights, etc. I now want to open org-noter and view the associated notes, or if no notes file exists, use org-roam-capture to create it.

Unfortunately, I can’t see any way of doing this at the moment. The best I can do is invoke org-noter and add notes to files listed in org-noter-default-files-name, so that all the notes end up in the same file.

Is there a function or hack I can use to get org-noter to search for an associated notes file for my .pdf, or use my org-roam-capture-template to create such a notes file?

If you look at the docstring of command org-noter, you will see this:

  • Creating the session from the document

This will try to find a notes file in any of the parent folders. The names it will search for are defined in `org-noter-default-notes-file-names’. It will also try to find a notes file with the same name as the document, giving it the maximum priority.

In the context of Org-noter, the “document” refers to the PDF document you want to annotate.

So I read it that if you have a PDF named “2022_nobiot.pdf”, it will first try to look for “” (probably in the same directory; I can’t confirm how the directory is determined)

This part is followed by this:

When it doesn’t find anything, it will interactively ask you what you want it to do. The target notes file must be in a parent folder (direct or otherwise) of the document.

You may pass a prefix ARG in order to make it let you choose the notes file, even if it finds one.

So… it seems you can do C-u org-noter and select an exact org file.

I haven’t tried these ways myself. I hope you will find a way without coding. Otherwise, you could consider overriding the part of the code.

Sorry for the slow response.

Thank you! This is indeed helpful - C-u M-x org-noter will call give me a list of possible files in my org-roam notes directory associated with the .pdf I’m looking for, including a new file with the same title as the pdf, i.e.

The remaining issue is the recognition of the notes file by helm-bibtex/org-ref/org-roam-bibtex. In order for this to work, what needs to happen is that the :PROPERTIES: drawer for the main headline in the notes file needs to include:

  • a new UUID for the :ID: property and
  • the org-ref citation link for the :ROAM_REFS: property.

So far, I have been able to add these manually, e.g. opening and doing M-x org-id-get-create and then opening the property drawer to add the :ROAM_REFS: property, then doing helm-bibtex and selecting the citation link to add to the field, so that it reads :ROAM_REFS: cite:2022_nobiot.

I would like this to happen automatically upon creating the notes file, but associating the citation link with the pdf file seems unwieldy.

At a quick glance, you could rather easily create your custom wrapper command around C-u M-x org-noter and add the two additional elements to be added to the note.

The following is just a sketch of the idea off top of my head right now – easier to convey it via code. It’s untested (I don’t use org-noter at the moment).

(defun my/org-noter-notes-from-pdf ()
  "Call from within the PDF document to create or open an org-noter file.
If it does not exist, create and add the following to the heading
command `org-noter' creates: - a new UUID for the :ID: property -
the org-ref citation link for the :ROAM_REFS: property."
  (org-noter t)
  ;; I am assuming your point is now at the heading in the org-noter
  ;; buffer `org-noter' has created Not sure if you need to do something
  ;; different when the file already exists
  (other-frame 1)
  (with-current-buffer (org-noter--session-notes-buffer org-noter--session)
     ;; You'd need to think of a reliable way to obtain the cite key of
     ;; the PDF document Here I'm assuming you can manually name the
     ;; file/buffer of the org-noter buffer as ""
     (org-set-property "ROAM_REFS"
                       (concat "cite:" (file-name-sans-extension
                                        (file-name-base (buffer-file-name)))))))

EDIT: This latest version did work but probably not robust – it assumes you work with only one frame normally, and only one new frame will always open for the Org-noter session.

Great, thanks very much!

As you say there are a few bugs here. First, I use Emacs in daemon mode and have a lot of client frames around. I tend to have a couple of org-noter buffers open looking at different pdf files, and when I tried to use your function on a particular document, the :ID: and :ROAM_REFS: properties were added to a headline in another open org-noter frame.

Secondly (and less problematically), if a notes file already exists with the appropriate name, it doesn’t just jump to it in the way that calling org-noter by itself does. But if you keep selecting the same filename etc, it will just open the pre-existing file in the end, so there’s no loss of information.

Thanks again for your help – I will try to tinker around with this when I can to see if I get somewhere.

In the wrapper, you can check the existence of the file (file-existp, or something) and then switch to calling org-noter on its own with no argument.

As for the first issue of determining the right frame, you could probably cycle them one by one and check the PDF file name in the “main window”(whatever that could mean)…

I only work with a single frame so hopefully others can jump in to assist…

Or alternatively, you could try (other-frame -1). I think you’d always want to select the newest frame just opened in this case. I have a feeling it could be added to the back of the list of frames and your “current one” is the first one (I can be completely wrong here — if so, I think cycling through frames until you get to the one is a valid logic).