[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21729: doc-view messed up by early auto-revert
From: |
Tassilo Horn |
Subject: |
bug#21729: doc-view messed up by early auto-revert |
Date: |
Thu, 22 Oct 2015 08:22:05 +0200 |
User-agent: |
Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> 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