GNU bug report logs -
#21729
doc-view messed up by early auto-revert
Previous Next
Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Thu, 22 Oct 2015 03:11:02 UTC
Severity: minor
Found in version 25.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #8 received at 21729 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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
This bug report was last modified 3 years and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.