org-ref drag & drop PDF error: "Invalid search bound (wrong side of point)"

Question

I drag and drop the pdf of this paper into a .bib file... doi:10.1136/bmj.39001.657755.BE

This error appears in the messages buffer:

[yas] Prepared just-in-time loading of snippets successfully.
For information about GNU Emacs and the GNU system, type C-h C-a.
looking-back: Invalid search bound (wrong side of point)

Backtrace:
Debugger entered--Lisp error: (error "Invalid search bound (wrong side of point)")
  re-search-backward("\\(?:\n\n\\)\\=" 3 t)
  looking-back("\n\n" 3)
  doi-utils-add-bibtex-entry-from-doi("10.1136/bmj.39001.657755.BE" "/Users/williamobrien/test.bib")
  org-ref-pdf-dnd-protocol("file:/Users/williamobrien/bibliography/bibtex-pdfs/hallan06_screen_strat_chron_kidney_diseas_gener_popul.pdf" private)
  dnd-handle-one-url(#<window 3 on test.bib> private "file:/Users/williamobrien/bibliography/bibtex-pdfs/hallan06_screen_strat_chron_kidney_diseas_gener_popul.pdf")
  ns-drag-n-drop((drag-n-drop (#<window 3 on test.bib> 2 (215 . 239) 0 nil 2 (30 . 1) nil (215 . 225) (7 . 14)) (file "/Users/williamobrien/bibliography/bibtex-pdfs/hallan06_screen_strat_chron_kidney_diseas_gener_popul.pdf")))
  funcall-interactively(ns-drag-n-drop (drag-n-drop (#<window 3 on test.bib> 2 (215 . 239) 0 nil 2 (30 . 1) nil (215 . 225) (7 . 14)) (file "/Users/williamobrien/bibliography/bibtex-pdfs/hallan06_screen_strat_chron_kidney_diseas_gener_popul.pdf")))
  call-interactively(ns-drag-n-drop nil nil)
  command-execute(ns-drag-n-drop)

Emacs version 25.1.1 and org-ref installed from melpa today.

Does anyone else get the same error for this journal article?

Answer 1

Raise a bug report with the author of org-ref.

doi-utils-add-bibtex-entry-from-doi in doi-utils.el of that package does this:

(when (not (looking-back "\n\n" 3))
  (insert "\n\n"))

Which is a very odd-looking constraint, but then I really don't know anything about this code or its usage.

Clearly in your instance, point is < 3, so that triggers an error. You could possibly work around it in the interim by changing that code as follows, but I don't know if the end result would be as desired. I'd say that the author ought to review this function.

(when (not (looking-back "\n\n" (min 3 (point))))
  (insert "\n\n"))