Subject: bug#21729: doc-view messed up by early auto-revert

From: Tassilo Horn <[email-masked]>
Date: Thu, 22 Oct 2015 08:22:05 +0200

Stefan Monnier <[email-masked]> writes:

Hi Stefan,

> When I work on LaTeX documents, I generally have a doc-view-mode
> buffer open displaying the PDF output.  I'd like this document to
> auto-update after I recompile the .tex file(s), but using M-x
> auto-revert-mode doesn't work well for that:
>
>   emacs -Q foo.pdf
>   M-x auto-revert-mode RET
>
> then in a shell
>
>   pdflatex foo
>
> The result is that the doc-view buffer ends up displaying the raw
> file's content (for me anyway: it's timing dependent, but I see this
> behavior on several machines, with very different performance.  the
> foo.tex document needs to be large enough, of course).

Yes, I experienced the same problem although with the PDF Tools viewer
when I tried to enable `auto-revert-mode' in the PDF file buffer.  What
I do now instead is

--8<---------------cut here---------------start------------->8---
(defun th/pdf-view-revert-buffer-maybe (file)
  (when-let ((buf (find-buffer-visiting file)))
    (with-current-buffer buf
      (when (derived-mode-p 'pdf-view-mode)
	(pdf-view-revert-buffer nil t)))))

(add-hook 'TeX-after-TeX-LaTeX-command-finished-hook
	  #'th/pdf-view-revert-buffer-maybe)
--8<---------------cut here---------------end--------------->8---

i.e., I revert the buffer from an AUCTeX hook that's run after the
compilation has finished.

> I think there are two problems:
>
> - Doc-view should inhibit auto-revert when the file was modified too
>   recently (on the assumption that it's not complete yet).

Something like checking if the file's MTIME is more than a second ago?

Hm, no, that won't work.  I currently work on some large document (~450
pages).  When I compile that, the file changes several times per second
during the compilation, then it doesn't change for ~15 seconds while
latex (lualatex in this case) is still running, and then starts changing
again for maybe 3 seconds.

I think the long delay is caused by computing the index and
bibliography.  I just checked that during that period, actually no file
changes, e.g., neither pdf, aux, bcf, idx, etc.  The only thing I can
see is that there's a foo.synctex.gz(busy) file which really disappears
when the compilation has finished but of course nobody is required to
use synctex.

Well, one reasonably reliable way to test if a pdf file is correct is
calling pdfinfo (provided by poppler) on it.  A non-zero exit status
indicated that the file is broken/incomplete.  Should we use that?

> - [ Just guessing here: ] We may sometimes fail to revert the file
> after it's complete, maybe because the last reversion finished after
> the file was complete, even though it started before, so the last
> reversion failed to include some changes that were added while the
> buffer was being reverted.

Yeah, that's possible.  And I think there could also be a problem when
people use latexmk which compiles your document several times until all
refs are defined and its stable.  Here, we might revert exactly between
two latex runs.

Bye,
Tassilo