New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restarting continuous compilation breaks automatic pdf refreshing in Mupdf. #903

Closed
YesButWhyThough opened this Issue Jul 13, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@YesButWhyThough

YesButWhyThough commented Jul 13, 2017

Description

If continuous compilation is turned on then turned off, Mupdf will no longer automatically display an updated pdf after every write.

Minimal Working Example

  1. Open a TeX file, gvim -u ~/.minimalvimrc hello.tex
\documentclass{minimal}
\begin{document}

Hello World!

\end{document}
  1. Turn on continuous mode with \ll
  2. Make a change to the file, Mupdf will update with the new version.
\documentclass{minimal}
\begin{document}

Goodbye World!

\end{document}
  1. Turn off continuous mode \ll
  2. Turn on continuous mode \ll
  3. Make a change to the file, Mupdf will not update. Using :VimtexView does not force an update. Selecting the Mupdf window manually and pressing r will display the proper updated state of the PDF. However, doing so does not restore continuous updating.
\documentclass{minimal}
\begin{document}

Goodbye Cruel World!

\end{document}

Minimal vimrc file

set nocompatible
let &rtp  = '~/.vim/bundle/vimtex,' . &rtp
let &rtp .= ',~/.vim/bundle/vimtex/after'
filetype plugin indent on
syntax enable
let g:vimtex_view_method = 'mupdf'
set runtimepath^=~/.vim/plugged/vimtex "Plugin Location. 

lervag added a commit that referenced this issue Jul 14, 2017

@lervag

This comment has been minimized.

Show comment
Hide comment
@lervag

lervag Jul 14, 2017

Owner

Thanks, I've reproduced this. I'll look into it when I get the time.

Note, though, that I suspect that this might be difficult to fix. If I remember correctly, latexmk updates mupdf through signals, and this is set up when mupdf is opened from latexmk. I suspect that we see the same problem if you start the viewer manually with \lv, then start compilation afterwords. In any case, I'll see what I can do...

Owner

lervag commented Jul 14, 2017

Thanks, I've reproduced this. I'll look into it when I get the time.

Note, though, that I suspect that this might be difficult to fix. If I remember correctly, latexmk updates mupdf through signals, and this is set up when mupdf is opened from latexmk. I suspect that we see the same problem if you start the viewer manually with \lv, then start compilation afterwords. In any case, I'll see what I can do...

@lervag lervag closed this in 9a3db9c Jul 16, 2017

@lervag

This comment has been minimized.

Show comment
Hide comment
@lervag

lervag Jul 16, 2017

Owner

Ok, I've tried to fix this by using manual refreshes if possible. This means that MuPDF is refreshed from Vim, not from latexmk. It only works if you use the callback feature, but it looked like you already did.

Note though, that this will only update MuPDF on successful compiles.

I hope you agree this solves the issue.

Owner

lervag commented Jul 16, 2017

Ok, I've tried to fix this by using manual refreshes if possible. This means that MuPDF is refreshed from Vim, not from latexmk. It only works if you use the callback feature, but it looked like you already did.

Note though, that this will only update MuPDF on successful compiles.

I hope you agree this solves the issue.

@gkapfham

This comment has been minimized.

Show comment
Hide comment
@gkapfham

gkapfham Jul 19, 2017

Hello again @lervag! Thanks again for your continued development of vimtex. As you know, I use the plugin frequently and I really appreciate the time and knowledge that you invest into the development and maintenance of it.

I am speculating that the code you added to handle this request may have caused some of the key features of vimtex to stop working with nvim.

When I used exactly the minimal .vimrc file and minimal.tex and NVIM v0.2.1-dev with a correct :CheckHealth and a correctly working nvr I no longer see vimtex working correctly.

For instance, if I load the minimal.tex file and then run \ll the mupdf window does not load automatically. However, if I run \lv this will correctly load the mupdf window. Yet, now I have to always press r inside of mupdf to see the changes to the document.

Interestingly, I cannot reproduce this issue with VIM - Vi IMproved 8.0 Included patches: 1-134. That is, the minimal example will work as expected with vim but not work with nvim.

Moreover, I can confirm that I see exactly this same behaviour, for both nvim and vim, when I use my full .vimrc file and any of the papers that I am currently writing in LaTeX. That is, \ll brings up mupdf correctly and it reloads on changes when using vim and this expected behaviour is not evident when using nvim.

Finally, I looked at the source code commit referenced in this issue. The conditional logic suggested that if the callback variable was 0, then the SIGHUP command would be run as expected. So, I added this to my .vimrc file to see what behaviour I would observe:

let g:vimtex_compiler_latexmk = {
    \ 'backend' : 'nvim',
    \ 'background' : 1,
    \ 'build_dir' : '',
    \ 'callback' : 0,
    \ 'continuous' : 1,
    \ 'executable' : 'latexmk',
    \ 'options' : [
    \   '-pdf',
    \   '-verbose',
    \   '-file-line-error',
    \   '-synctex=1',
    \   '-interaction=nonstopmode',
    \ ],
\}

Please note that this above configuration is only run if has('nvim') returns 1. Now, if I perform the aforementioned steps I find that the anticipated behaviour appears in both nvim and vim! That is, running the compiler will immediately start mupdf which will then always refresh when changes are made to the LaTeX file. So, what value is appropriate for callback? After re-reading the vimtex documentation, it seems that callback would give me the error reports, which I still seem to receive in nvim even when the variable is set to 0.

Okay, I hope that this comment has given you an acceptable description of what I am observing. Please let me know if you need more details. If you can advise as to whether the new approach has a problem or whether I should always be setting callback to 0 now, I would appreciate your insights!

gkapfham commented Jul 19, 2017

Hello again @lervag! Thanks again for your continued development of vimtex. As you know, I use the plugin frequently and I really appreciate the time and knowledge that you invest into the development and maintenance of it.

I am speculating that the code you added to handle this request may have caused some of the key features of vimtex to stop working with nvim.

When I used exactly the minimal .vimrc file and minimal.tex and NVIM v0.2.1-dev with a correct :CheckHealth and a correctly working nvr I no longer see vimtex working correctly.

For instance, if I load the minimal.tex file and then run \ll the mupdf window does not load automatically. However, if I run \lv this will correctly load the mupdf window. Yet, now I have to always press r inside of mupdf to see the changes to the document.

Interestingly, I cannot reproduce this issue with VIM - Vi IMproved 8.0 Included patches: 1-134. That is, the minimal example will work as expected with vim but not work with nvim.

Moreover, I can confirm that I see exactly this same behaviour, for both nvim and vim, when I use my full .vimrc file and any of the papers that I am currently writing in LaTeX. That is, \ll brings up mupdf correctly and it reloads on changes when using vim and this expected behaviour is not evident when using nvim.

Finally, I looked at the source code commit referenced in this issue. The conditional logic suggested that if the callback variable was 0, then the SIGHUP command would be run as expected. So, I added this to my .vimrc file to see what behaviour I would observe:

let g:vimtex_compiler_latexmk = {
    \ 'backend' : 'nvim',
    \ 'background' : 1,
    \ 'build_dir' : '',
    \ 'callback' : 0,
    \ 'continuous' : 1,
    \ 'executable' : 'latexmk',
    \ 'options' : [
    \   '-pdf',
    \   '-verbose',
    \   '-file-line-error',
    \   '-synctex=1',
    \   '-interaction=nonstopmode',
    \ ],
\}

Please note that this above configuration is only run if has('nvim') returns 1. Now, if I perform the aforementioned steps I find that the anticipated behaviour appears in both nvim and vim! That is, running the compiler will immediately start mupdf which will then always refresh when changes are made to the LaTeX file. So, what value is appropriate for callback? After re-reading the vimtex documentation, it seems that callback would give me the error reports, which I still seem to receive in nvim even when the variable is set to 0.

Okay, I hope that this comment has given you an acceptable description of what I am observing. Please let me know if you need more details. If you can advise as to whether the new approach has a problem or whether I should always be setting callback to 0 now, I would appreciate your insights!

@lervag

This comment has been minimized.

Show comment
Hide comment
@lervag

lervag Jul 20, 2017

Owner

@gkapfham Hi. Sorry that the last update break things for you! The point of that change was that instead of relying on latexmk to pass signals to MuPDF, vimtex would do it. This is possible whenever the callback feature is activated, and so it should work if the callbacks work. Further, the point was that if we rely on latexmk to pass the signals, MuPDF will not update automatically if you for some reason close the viewer and then open again with \lv (as explained by the original post in this issue). Thus, my change was supposed to fix this by letting vimtex pass the r key to update MuPDF with xdotools.

However, I am now thinking that I can sort of combine both of these ideas. That is, I guess it will never hurt to make MuPDF refresh from the callbacks, and it seems to fix the current issue. However, there does not seem to be a good reason not to allow latexmk to refresh when that is possible. So I pushed a commit that should fix this. Please test.

Owner

lervag commented Jul 20, 2017

@gkapfham Hi. Sorry that the last update break things for you! The point of that change was that instead of relying on latexmk to pass signals to MuPDF, vimtex would do it. This is possible whenever the callback feature is activated, and so it should work if the callbacks work. Further, the point was that if we rely on latexmk to pass the signals, MuPDF will not update automatically if you for some reason close the viewer and then open again with \lv (as explained by the original post in this issue). Thus, my change was supposed to fix this by letting vimtex pass the r key to update MuPDF with xdotools.

However, I am now thinking that I can sort of combine both of these ideas. That is, I guess it will never hurt to make MuPDF refresh from the callbacks, and it seems to fix the current issue. However, there does not seem to be a good reason not to allow latexmk to refresh when that is possible. So I pushed a commit that should fix this. Please test.

@gkapfham

This comment has been minimized.

Show comment
Hide comment
@gkapfham

gkapfham Jul 20, 2017

Hello again @lervag! I am writing to confirm that the most recent update seems to resolve the issue for me. I can now correctly edit and compile papers with vimtex using my standard workflow in nvim. I will keep you updated as to whether I notice any further problems related to this issue. Thanks for the fix!

gkapfham commented Jul 20, 2017

Hello again @lervag! I am writing to confirm that the most recent update seems to resolve the issue for me. I can now correctly edit and compile papers with vimtex using my standard workflow in nvim. I will keep you updated as to whether I notice any further problems related to this issue. Thanks for the fix!

@lervag

This comment has been minimized.

Show comment
Hide comment
@lervag

lervag Jul 23, 2017

Owner

Great, thanks. And no problem :)

Owner

lervag commented Jul 23, 2017

Great, thanks. And no problem :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment