unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Tassilo Horn <tsdh@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 21729@debbugs.gnu.org
Subject: bug#21729: doc-view messed up by early auto-revert
Date: Thu, 22 Oct 2015 08:22:05 +0200	[thread overview]
Message-ID: <874mhjtoc2.fsf@gnu.org> (raw)
In-Reply-To: <jwv8u6wgkqv.fsf@iro.umontreal.ca> (Stefan Monnier's message of "Wed, 21 Oct 2015 14:05:44 -0400")

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	other threads:[~2015-10-22  6:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-21 18:05 bug#21729: doc-view messed up by early auto-revert Stefan Monnier
2015-10-22  6:22 ` Tassilo Horn [this message]
2015-10-22 13:10   ` Stefan Monnier
2015-10-22 15:11     ` Tassilo Horn
2015-10-23  9:33       ` Nicolas Richard
2015-10-23 10:08         ` Tassilo Horn
2019-09-29 13:03           ` Lars Ingebrigtsen
2019-10-03  9:21             ` Tassilo Horn
2022-02-03 21:01               ` Lars Ingebrigtsen
2019-10-03 13:31           ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874mhjtoc2.fsf@gnu.org \
    --to=tsdh@gnu.org \
    --cc=21729@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).