LaTeX composition in (g)vim with live update-as-you-type PDF preview

guga31bb · 2010-11-04 22:19:02

I've been using this some more and overall I think it's great.

One annoyance has been that sometimes mupdf changes pages (goes back one page) without me telling it to. For example, I'll hit \f to go to my current page, then start editing something, and look over to see that it's no longer on the same page. If you haven't seen this behavior I'll try to see whether I can reproduce it.

Other than that, it seems to work perfectly. A couple suggestions:
--it's really hard to look through the pdf without taking your hands off the keyboard. hitting \ + (arrow or page up) is not very convenient. maybe i should change my leader or the commands for page changing?
--it would be nice to have a way for the pdf to follow where you are (eg automatically pressing \f every few seconds)

Also, when trying this in vim, it seemed extremely buggy. once i installed gvim, all the problems went away.

Anyways good work!

EDIT -- when you update this, how do I get the newest version? If I use yaourt, can I just yaourt -Syu? Sorry for the newbie questions=)

EDIT 2 -- on changing pages. When I go into insert mode in a footnote, when I press "i" it brings me back to the page that footnote's number is on (even though I didn't tell mupdf to do anything).

Last edited by guga31bb (2010-11-04 22:26:42)

frabjous · 2010-11-04 22:37:04

Hey, guga. Thanks for the feedback. It is appreciated.

Do you know what version you're using? If it's less than 0.3, could you try updating to the newest one, and see if the problems in regular vim are gone?

Another feature I added later was that it does a forward search (jumps to the right page: same thing as \f) whenever you switch from normal to Insert mode in vim. This was my way of getting something like what you hint at at the end of a "periodic \f". Usually, I don't go long in vim without going in and out of insert mode, so this does the trick for me.

Then again, it might be the reason for mupdf moving around when you don't tell it to... which otherwise is a bit mysterious. The only other possible explanation I could have for that is that mupdf always goes back to the top of the page when it refreshes. It shouldn't switch pages, but if the entire page wasn't visible, it might no longer show the same part of the page you were looking at before. That's just how MuPDF works, and I woudn't be able to change it without modifying mupdf. (Of course, that's possible, since it's open source, but I don't know C personally.) I personally always keep the entire page visible at once, so it doesn't matter.

As for the key-bindings, by all means, customize them and add to them. Here are the default ones.

nnoremap <silent> <buffer> <LocalLeader>p :call LaunchMuPDF()<CR>
nnoremap <silent> <buffer> <LocalLeader>o :call CloseMuPDF()<CR>
nnoremap <silent> <buffer> <LocalLeader>s :call CheckLiveUpdateStatus()<CR>
nnoremap <silent> <buffer> <LocalLeader>f :call MuPDFForward()<CR>
nnoremap <silent> <buffer> <LocalLeader>r :call MuPDFReverse()<CR>
nnoremap <silent> <buffer> <LocalLeader>c :exec "silent! !live-latex-update.sh \"" . b:Rootfile . "\" " . b:MuPDFWindowID . " &"<CR>
nnoremap <silent> <buffer> <LocalLeader><PageDown> :silent! call system("xdotool key --window " . b:MuPDFWindowID . " Page_Down")<CR>
nnoremap <silent> <buffer> <LocalLeader><PageUp> :silent! call system("xdotool key --window " . b:MuPDFWindowID . " Page_Up")<CR>
nnoremap <silent> <buffer> <LocalLeader><Up> :silent! call system("xdotool key --window " . b:MuPDFWindowID . " Up")<CR>
nnoremap <silent> <buffer> <LocalLeader><Down> :silent! call system("xdotool key --window " . b:MuPDFWindowID . " Down")<CR>
nnoremap <silent> <buffer> <LocalLeader><Left> :silent! call system("xdotool key --window " . b:MuPDFWindowID . " Left")<CR>
nnoremap <silent> <buffer> <LocalLeader><Right> :silent! call system("xdotool key --window " . b:MuPDFWindowID . " Right")<CR>
nnoremap <silent> <buffer> <LocalLeader>G :silent! call system("xdotool key --window " . b:MuPDFWindowID . " G")<CR>
nnoremap <silent> <buffer> <LocalLeader>m :silent! call system("xdotool key --window " . b:MuPDFWindowID . " m")<CR>
nnoremap <silent> <buffer> <LocalLeader>t :silent! call system("xdotool key --window " . b:MuPDFWindowID . " t")<CR>
nnoremap <silent> <buffer> <LocalLeader>- :silent! call system("xdotool key --window " . b:MuPDFWindowID . " minus")<CR>
nnoremap <silent> <buffer> <LocalLeader>+ :silent! call system("xdotool key --window " . b:MuPDFWindowID . " plus")<CR>
nnoremap <silent> <buffer> <LocalLeader>= :silent! call system("xdotool key --window " . b:MuPDFWindowID . " equal")<CR>

Hopefully the function-names are self-explanatory. Just define your own mappings calling the same functions (i.e., changing <LocalLeader><PageUp> to whatever you want), and put them in ~/.vim/ftplugin/tex.vim. (If you want to disable these, you can put:

let no_tex_maps = 1

in your .vimrc.) (Or you can edit /usr/share/vim/vim73/ftplugin/tex/live-latex-preview.vim as root to change them at the source.)

There's also no reason not to just switch keyboard focus to the MuPDF preview window and use MuPDF's own key mappings to navigate around.

Last edited by frabjous (2010-11-04 22:39:33)

guga31bb · 2010-11-04 23:35:27

frabjous wrote:

Do you know what version you're using? If it's less than 0.3, could you try updating to the newest one, and see if the problems in regular vim are gone?

Yep it was 0.2. I updated and now everything seems to work just as well in vim as in gvim.

frabjous wrote:

Another feature I added later was that it does a forward search (jumps to the right page: same thing as \f) whenever you switch from normal to Insert mode in vim. This was my way of getting something like what you hint at at the end of a "periodic \f". Usually, I don't go long in vim without going in and out of insert mode, so this does the trick for me.
Then again, it might be the reason for mupdf moving around when you don't tell it to... which otherwise is a bit mysterious.

This was precisely the problem (if you could call it that). What happened is that I was working on a footnote which spilled over to the next page, so I could never see what I was working on since mupdf was determined to stay on the page where the footnote started. I don't think this is much of a problem and probably isn't worth your time to fix.

As always, thanks for your very helpful replies! I plan on continuing to use this so I'll post if I find anything else.

Army · 2010-11-21 16:33:46

Am I doing something wrong or is this vim plugin compiling the latex code even when I stopped the live preview with \o ? My computer is always working, which causes vim to be a bit laggy and I really hate that.

frabjous · 2010-11-21 16:44:15

Army wrote:

Am I doing something wrong or is this vim plugin compiling the latex code even when I stopped the live preview with \o ? My computer is always working, which causes vim to be a bit laggy and I really hate that.

It does not continue to compile after you do \o to turn off the plugin. It does however, continue to save the file with each keystroke, which may be responsible for vim being a bit laggy, especially on an older system. If you want it to only save with each keystroke when the preview is active, edit /usr/share/vim/vim73/ftplugin/tex/live-latex-preview.vim and change:

function! UpdatePDF()
   if filewritable(bufname("%"))
       silent update
       if b:Pdfviewing == "yes"
            silent! exec "silent! !live-latex-check.sh \"" . b:Rootfile . "\" \"" . expand("%") . "\" " . b:MuPDFWindowID . " &" 
       endif
   endif
endfunction

to

function! UpdatePDF()
   if filewritable(bufname("%"))
       if b:Pdfviewing == "yes"
            silent update
            silent! exec "silent! !live-latex-check.sh \"" . b:Rootfile . "\" \"" . expand("%") . "\" " . b:MuPDFWindowID . " &" 
       endif
   endif
endfunction

(I.e., move the third line two lines down). (Then restart vim.)

Army · 2010-11-21 16:56:41

Great! Thanks!

frabjous · 2010-11-21 21:14:46

I'm going to have to update the scripts on account of some changes to the GNU coreutils between 8.6 and 8.7 which has slowed down the script and made it more likely to get stuck. It's an easy fix. But as long as I'm repackaging it, do people want the script to be changed as I suggested to Army above, so that it doesn't auto-save when the preview is not active, or keep it the way it was?

Personally, I like it the original way, since I've become used to my file always being saved and worry that I'll forget if I change it, but perhaps this is too heavyhanded for others. Thoughts?

Army · 2010-11-21 22:32:48

Any chance that this can be configured with a config file? That way the user can decide. If it's not possible, I might have to add that I'm on a laptop, which of course has a slower hdd, and I use xfs, which might be the reason why this affects me more than others. I could test it with another laptop hdd which is formatted with nilfs2 (I wanted to test this new filesystem). If then vim doesn't lag, it would be better to leave it as it is right now, maybe with a comment in the source code, so it can easily be modified.

guga31bb · 2010-11-22 00:21:48

I think not auto-saving when the preview is not active is a reasonable default, but making it easy to change (config file or option or something) would be the best route.

frabjous · 2010-11-23 05:46:04

OK, new version uploaded to AUR. In this one, by default, it only autosaves when the preview is on. If you want it to autosave a .tex document even when the preview is off, you need only put:

let tex_preview_always_autosave = 1

in your .vimrc.

I've also changed how the script checks whether or not a new compilation is needed to make it compatible with changes to the stat tool from GNU coreutils v8.7, which should make the script less prone to get "stuck" a few edits behind. (Long story.)

Army · 2010-11-23 08:10:28

Ok, that's a great compromise!

Last edited by Army (2010-11-23 08:10:39)

Sara · 2010-11-28 05:32:21

Is there any chance of this working with llpp, which is based off of mupdf? I tried editing the mupdf-launch.sh file, replacing instances of MuPDF with llpp, and the launcher from mupdf to llpp, but it didn't work (note that I'm using a patch that makes llpp issue a window title which the author sent me. At the moment, I don't think this changed has been pushed to his git repo).

I've posted the patch to llpp to the archlinux pastebin in case anyone is interested:
http://archlinux.pastebin.com/raw.php?i=bN0FrfTz

Last edited by Sara (2010-11-28 05:37:42)

frabjous · 2010-11-28 06:16:12

I tried llpp briefly hoping it might offer some advantages, but I didn't get very far with it. It didn't help that llpp -- or at least the version I installed a few weeks ago -- has no man page and no useful --help option, but as of now, it does not seem possible to do the same things with it. In particular:

(1) as far as I can tell, there is no way at all to get llpp to update or refresh the PDF it is viewing; no keystroke or anything else short of shutting it down and restarting it. (Perhaps I'm wrong about that; I found no list of keybindings anywhere.) My script refreshes the page by sending the 'r' key (which mupdf uses for refresh) to mupdf after any successful compilation. I don't know how to accomplish the same with llpp. This is of course a dealbreaker.

(2) This is less serious, but when llpp is running, no window class for the windows it creates is ever set, and the window title is just the name of the PDF; it does not even include 'llpp' anywhere; this would throw a lot of guesswork into trying to figure out which window xdotool should interact with. Perhaps the patch you mention would modify that, however.

Even then it wouldn't include the page number for reverse searches. But if llpp is in active development, perhaps far better to encourage the devs for it to support SyncTeX forward/reverse searches directly (that way you could make them far more accurate). If they did that, and provided a way for either an external program or keystroke (activated by xdotool) to refresh its display, then it could probably work well.

Last edited by frabjous (2010-11-28 06:17:59)

Sara · 2010-11-28 07:31:21

frabjous wrote:

I tried llpp briefly hoping it might offer some advantages, but I didn't get very far with it. It didn't help that llpp -- or at least the version I installed a few weeks ago -- has no man page and no useful --help option, but as of now, it does not seem possible to do the same things with it. In particular:
(1) as far as I can tell, there is no way at all to get llpp to update or refresh the PDF it is viewing; no keystroke or anything else short of shutting it down and restarting it. (Perhaps I'm wrong about that; I found no list of keybindings anywhere.) My script refreshes the page by sending the 'r' key (which mupdf uses for refresh) to mupdf after any successful compilation. I don't know how to accomplish the same with llpp. This is of course a dealbreaker.
(2) This is less serious, but when llpp is running, no window class for the windows it creates is ever set, and the window title is just the name of the PDF; it does not even include 'llpp' anywhere; this would throw a lot of guesswork into trying to figure out which window xdotool should interact with. Perhaps the patch you mention would modify that, however.
Even then it wouldn't include the page number for reverse searches. But if llpp is in active development, perhaps far better to encourage the devs for it to support SyncTeX forward/reverse searches directly (that way you could make them far more accurate). If they did that, and provided a way for either an external program or keystroke (activated by xdotool) to refresh its display, then it could probably work well.

Here's the list of keybindings (like you, I was surprised at the --help option, but googling pulled this up):
http://repo.or.cz/w/llpp.git/blob/ba5f7 … cd06:/KEYS

The patch does fix it, as I tested it with xprop to check (I requested the patch as I needed llpp to issue a window class in order to tag its window in dwm, and as it's now working properly with dwm, I'm 100% positive it works).

Thank you for carefully outlining the issues. I can't fix issue number one, but perhaps the keybindings I cited will offer a clue. I'll add persuading the developer to support SyncTeX to my todo list .

frabjous · 2010-11-28 13:57:59

Thanks for finding the keybindings. There is some interesting stuff in there -- features I didn't know it had, but nothing that would solve the larger problem. I think I'll put in a feature request for a reload option.

Incidentally, if you hadn't heard, Zathura may be switching from a poppler backend to a mupdf backend, and that might be another option once it's ready.

ksira · 2011-02-04 16:17:27

Thanks frabjous, this program is exacty what I need for my PhD thesis. Has there been any further development with it?

frabjous · 2011-02-04 17:01:31

Nothing important. If you can think of any possible improvements, let me know.

Army · 2011-02-05 10:24:28

I have problems with mupdf, it doesn't automatically update anymore. I tried mupdf from the repos and mupdf-darcs from AUR. I always have to focus mupdf and update manually. Does anybody have an idea how I could fix this or what this might be caused by?

botzoboy · 2011-02-05 10:52:45

Army wrote:

I have problems with mupdf, it doesn't automatically update anymore. I tried mupdf from the repos and mupdf-darcs from AUR. I always have to focus mupdf and update manually. Does anybody have an idea how I could fix this or what this might be caused by?

I have the same problem.

Army · 2011-02-05 15:15:00

I can't imagine that this is the reason for this problem, but when it worked I used xfs for both / and /home, now I use ext4. Maybe we can narrow it down so I can write a fully informative bug report.

frabjous · 2011-02-05 15:16:34

The problem wouldn't be with mupdf. It's either with your LaTeX document (--it doesn't update if there are errors in it--), or with xdotool. Without more information, I cannot diagnose. Create a minimal "Hello World" type document and see if it works with it.

essence-of-foo · 2011-02-05 18:35:02

Just for completeness: The Emacs people have a different approach to this: http://www.gnu.org/software/auctex/screenshots.html (No flamewar intended. I'm a Vim user myself)

frabjous · 2011-02-05 18:41:57

@Army I can't imagine either why the fs type would make any difference, and FWIW, I've only ever used ext3 or ext4.

@essence-of-foo Actually, the whizzytex plugin for emacs is far closer to this than the preview-latex feature of the AucTeX plugin (which is a quite different kind of feature than what I'm after with this, and I have no desire for it).

Last edited by frabjous (2011-02-05 18:42:36)

Army · 2011-02-05 19:23:39

frabjous wrote:

The problem wouldn't be with mupdf. It's either with your LaTeX document (--it doesn't update if there are errors in it--), or with xdotool. Without more information, I cannot diagnose. Create a minimal "Hello World" type document and see if it works with it.

The pdf file IS being updated, because as soon as I hit "r" in mupdf it shows all the new content. But you are right, I just created a very basic file

\documentclass[a4paper]{article}
\begin{document}
text
\end{document}

and it works. When I do a normal compilation of my big tex file (typing \ll in vim with installed vim-latexsuite-svn) there are some error messages (stuff like "overfull \hbox" etc.), but I guess (hope) they are normal. Is it possible that the way vim-live-latex-preview compiles the tex file is more sensible about errors? E.g. I sometimes don't have image files I already put into the tex file.

I'll have to start a new document in a few days, then I'll take a closer look what causes this.

EDIT: I looked closely into the tex file I'm working on right now and fixed all errors. Now everything's back to normal. Clearly, I'm a latex beginner, so I made some stupid mistakes. Hope I'll improve fast Thanks anyway!

But still, I don't get it, why did mupdf show the added stuff after pressing "r" to update?

Last edited by Army (2011-02-05 21:11:50)

frabjous · 2011-02-06 00:28:27

I set it up so the preview is updated just in case pdflatex returns a 0 exit status. There is a difference between a "warning" and "error" for LaTeX files, and this plays out in that warnings won't make pdflatex return a non-zero exit status, but errors will. Things like overfull/underfull boxes are just warnings, so they shouldn't stop it from updating. But more serious errors will.

pdflatex will often, though not always, still produce a PDF even if there are errors, and in those cases you could see the result in mupdf by manually hitting "r", which was probably what you were seeing. But I deliberately avoiding having it auto-refresh in such cases, partly because (1) it made it more obvious when there was an error and forced me to fix it right away, and (2) it prevents mupdf from trying to load a PDF that might be corrupted or missing.

This seemed like the right way to handle it, so file this under "Not a bug, a feature!"

By the way, while the preview is active, you can check the result of the last compilation with \s in vim normal mode. It should either show "success", or show "Error"; if the error is in the document you're editing, it should even jump you to the line containing the error and show a brief description of the error taken from the .log file. If the error is in a different document, it just tells you there's an error.

This isn't meant to be a replacement for making use of the more sophisticated error handling techniques other plugins provide, or a replacement for looking at the .log. I mainly just put in for cases like these where the preview seems stuck and you wanted to check whether errors were causing it, or just a lagging compilation, etc.

Last edited by frabjous (2011-02-06 00:29:40)

Arch Linux

#26 2010-11-04 22:19:02

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#27 2010-11-04 22:37:04

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#28 2010-11-04 23:35:27

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#29 2010-11-21 16:33:46

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#30 2010-11-21 16:44:15

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#31 2010-11-21 16:56:41

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#32 2010-11-21 21:14:46

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#33 2010-11-21 22:32:48

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#34 2010-11-22 00:21:48

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#35 2010-11-23 05:46:04

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#36 2010-11-23 08:10:28

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#37 2010-11-28 05:32:21

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#38 2010-11-28 06:16:12

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#39 2010-11-28 07:31:21

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#40 2010-11-28 13:57:59

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#41 2011-02-04 16:17:27

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#42 2011-02-04 17:01:31

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#43 2011-02-05 10:24:28

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#44 2011-02-05 10:52:45

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#45 2011-02-05 15:15:00

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#46 2011-02-05 15:16:34

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#47 2011-02-05 18:35:02

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#48 2011-02-05 18:41:57

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#49 2011-02-05 19:23:39

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

#50 2011-02-06 00:28:27

Re: LaTeX composition in (g)vim with live update-as-you-type PDF preview

Board footer