tools/pdf: build epdfinfo when pdf-tools is built

This fixes a number of UX issues with pdf-tools trying to eagerly build
epdfinfo at the least appropriate times, e.g. when org-mode processes
org-pdf-tools links.

Mentioned in #5086
This commit is contained in:
Henrik Lissner 2021-05-24 01:36:42 -04:00
parent 6321b3a249
commit eb9b7b0bbc
2 changed files with 14 additions and 34 deletions

View file

@ -27,39 +27,6 @@
(letf! ((#'pdf-tools-pdf-buffer-p #'ignore))
(apply orig-fn args)))
(defadvice! +pdf--install-epdfinfo-a (orig-fn &rest args)
"Install epdfinfo after the first PDF file, if needed."
:around #'pdf-view-mode
;; Prevent "epdfinfo not an executable" error short-circuiting this advice
(prog1 (with-demoted-errors "%s" (apply orig-fn args))
;; ...so we can go ahead and install it afterwards.
(cond ((file-executable-p pdf-info-epdfinfo-program))
((y-or-n-p "To read PDFs in Emacs the epdfinfo program must be built. Build it now?")
(message nil) ; flush lingering prompt in echo-area
;; Make sure this doesn't run more than once
(advice-remove #'pdf-view-mode #'+pdf--install-epdfinfo-a)
(unless (or (pdf-info-running-p)
(ignore-errors (pdf-info-check-epdfinfo) t))
;; HACK On the first pdf you open (before pdf-tools loaded)
;; `pdf-tools-install' throws errors because it has hardcoded
;; opinions about what buffer should be focused when it is run.
;; These errors cause `compile' to position the compilation
;; window incorrectly or can interfere with the opening of the
;; original pdf--sometimes aborting/burying it altogether. A
;; timer works around this.
(run-at-time
0.1 nil
(lambda ()
(with-current-buffer (pdf-tools-install t)
(add-hook! 'compilation-finish-functions :local
(dolist (buf (buffer-list))
(with-current-buffer buf
(and (buffer-file-name)
(or (pdf-tools-pdf-buffer-p)
(derived-mode-p 'pdf-view-mode))
(revert-buffer t t))))))))))
((message "Aborted")))))
(pdf-tools-install-noverify)
;; For consistency with other special modes