Feature request: reload file

[frxstrem]

As I use pdf-view for viewing PDF files that are contiously updated, sometimes it will try to reload the PDF file when there is no such file, and fail. (Example: compiling a LaTeX file into a PDF fails.) If this happens, I currently have to close and reopen the file.

Therefore I suggest having a context-menu option or a keyboard shortcut that I could use to quickly reopen the file, without having to close and reopen its tab.

[izuzak]

@frxstrem Thanks for the feedback!

I'm not sure I understand what problem you're actually seeing. Could you provide step-by-step instructions to reproduce this (if possible with just Atom and console commands, not using any external tools)? I don't understand in which way pdf-view fails for you and why that forces you to close and reopen the file exactly. Just want to make sure I understand what's happening and how that's not expected, so that I can see what can be improved.

Thanks again!

[frxstrem]

1. I open a .tex file and compile it successfully(I use the latex package to compile LaTeX documents inside Atom, which in turn uses the command line utility latexmk).
2. I open the PDF file that is produced.
3. I recompile the LaTeX document, but introduce some error that makes compilation fail. The output PDF file that was opened with pdf-view is deleted.
4. pdf-view apparently tries to reopen the file when it detects that a change has occurred, but fails and throws the exception below. The pdf pane is at this point empty, and even after the pdf file has been successfully recompiled, the pane does not reopen it. Thus I have to manually close the pane and open the pdf file again.

Uncaught Error: ENOENT: no such file or directory, open 'C:\Users\Fredrik\Documents\uio\MAT1110\2\oblig2.pdf'

At fs.js:519

Error: ENOENT: no such file or directory, open 'C:\Users\Fredrik\Documents\uio\MAT1110\2\oblig2.pdf'
  at Error (native)
  at Object.fs.openSync (fs.js:544:18)
  at Object.module.(anonymous function) [as openSync] (ATOM_SHELL_ASAR.js:118:20)
  at Object.fs.readFileSync (fs.js:396:15)
  at Object.fs.readFileSync (ATOM_SHELL_ASAR.js:369:29)
  at PdfEditorView.module.exports.PdfEditorView.updatePdf (C:\Users\Fredrik\.atom\packages\pdf-view\lib\pdf-editor-view.coffee:101:33)
  at C:\Users\Fredrik\.atom\packages\pdf-view\lib\pdf-editor-view.coffee:41:10
  at later (C:\Users\Fredrik\AppData\Local\atom\app-0.194.0\resources\app.asar\node_modules\underscore-plus\node_modules\underscore\underscore.js:724:25)

[izuzak]

Thanks. Can you reproduce the problem without using a latex compiler in the scenario? For example, does the problem happen if you just open a PDF file in Atom with pdf-view and then delete it on disk? If not, what's the difference there?

[frxstrem]

If I delete the file directly, nothing happens in pdf-view -- the file remains open. However, when I recompile with an error, I see that the file is first created and then deleted (in the fraction of a second), maybe this may be the difference that makes it behave erroneously?

[izuzak]

Great -- thanks for your help in investigating this! I'll need to install a latex compiler so that I can reproduce this.

[izuzak]

@frxstrem Sooo, I think I'll need more help with reproducing this. :grimacing: I installed latexmk and the latex package for Atom, and then followed the instructions you provided and couldn't reproduce this. Any error I introduce into the source tex file causes the "LaTeX compilation error" thing to show up in the status bar, but doesn't cause the exception.

Can you still reproduce this in Atom 0.199.0? If so, can you provide a sample tex file and clarify which change exactly you make to trigger this problem? It's possible I'm making "wrong" changes and not triggering the error somehow. Thanks again! :bow:

[timjb]

I've got a similar problem. I'm using pdf-view to see the compiled PDF beside the LaTeX source in Atom. Randomly, after compiling the LaTeX file, pdf-view fails to reload the PDF.

The issue seems to be that pdflatex writes the PDF continuously as it is compiling. (Some PDF viewers don't handle this well: for example, when you view a PDF in Mac OS X's Preview, and you switch to the window with the PDF file while regenerating that file with pdflatex, Preview crashes.) After looking at the code of pdf-view, I've got an idea of what's probably going on:

1. I start rebuilding my document: pdflatey mydocument.tex
2. pdflatex begins writing mydocument.pdf
3. atom-view detects the file change and begins reloading and rerendering the document
4. pdflatex finishes compiling
5. atom-view finishes rerendering the document, which results in a blank screen, because the version it tried to render wasn't a correct PDF file

The problem seems to be that file changes that occur while atom-view is refreshing do not trigger a new refresh.

@frxstrem This workaround may help in the meantime: This script builds the PDF file in a separate directory and moves the finished PDF into place afterwards (if there wasn't an error).

#!/bin/sh

set -e
pdflatex -output-directory output mydocument.tex
cp output/mydocument.pdf .

[izuzak]

Gonna call this one as closed by https://github.com/izuzak/atom-pdf-view/pull/67, but please let me know if you notice this again.