bug-gnu-emacs
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]