emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

refactor(pdf): better epdfinfo check on pdf-view-mode

Browse source 
Also adds a comment to explain why I don't directly call
pdf-tools-install, instead of pdf-tools-install-noverify.

Ref: #6589
This commit is contained in:
Henrik Lissner 2022-07-24 12:54:57 +02:00
parent 924d78443a
commit efb46c77be
No known key found for this signature in database
GPG key ID: B60957CA074D39A3
1 changed files with 13 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

14
modules/tools/pdf/config.el
View file

@ -21,13 +21,25 @@
(defadvice! +pdf--install-epdfinfo-a (fn &rest args)
"Install epdfinfo after the first PDF file, if needed."
:around #'pdf-view-mode
(if (file-executable-p pdf-info-epdfinfo-program)
(if (and (require 'pdf-info nil t)
(or (pdf-info-running-p)
(ignore-errors (pdf-info-check-epdfinfo) t)))
(apply fn args)
;; If we remain in pdf-view-mode, it'll spit out cryptic errors. This
;; graceful failure is better UX.
(fundamental-mode)
(message "Viewing PDFs in Emacs requires epdfinfo. Use `M-x pdf-tools-install' to build it")))
;; Despite its namesake, this does not call `pdf-tools-install', it only sets
;; up hooks, auto-mode-alist/magic-mode-alist entries, global modes, and
;; refreshes pdf-view-mode buffers, if any.
;;
;; I avoid calling `pdf-tools-install' directly because `pdf-tools' is easy to
;; prematurely load in the background (e.g. when exporting an org file or by
;; packages like org-pdftools). And I don't want pdf-tools to suddenly block
;; Emacs and spew out compiler output for a few minutes in those cases. It's
;; abysmal UX. The `pdf-view-mode' advice above works around this with a less
;; cryptic failure message, at least.
(pdf-tools-install-noverify)
;; For consistency with other special modes