Vim, Evince and forward and backward LaTeX synctex search

I was finally fed up with not having forward and backward search in vim so I hacked up the python script that was in the gedit synctex package to do what I needed. The result is evince_vim_dbus.py (GNOME 2.32 version) or evince_vim_dbus.py (GNOME 3 version old LaTeX) or evince_vim_dbus.py (GNOME 3 version that works with TexLive 2011). Copy it somewhere into your PATH (say ~/bin or /usr/local/bin). The first argument is EVINCE or GVIM. If it is EVINCE then it works just like the evince_dbus.py from the gedit synctex package. So to do forward search you add something like the following to your .vimrc file. This uses the LatexBox set of vim macros, which is pretty unobtrusive and kind of useful

function! LatexEvinceSearch()
execute "!cd " . LatexBox_GetTexRoot() . '; evince_vim_dbus.py EVINCE "`basename ' . LatexBox_GetOutputFile(). '`" ' . line('.') . ' "%:p"'
endfun
command! LatexEvinceSearch call LatexEvinceSearch()
au FileType tex map ls :silent LatexEvinceSearch


Make sure to compile your latex file with pdflatex –synctex=1 thefile. Now to jump to the right place in evince just type \ls in vim at the right spot. For vim-latex I assume something like the following would work though I have not tried so this may not actually work:

let g:Tex_ViewRule_pdf = 'evince_vim_dbus.py EVINCE'
let g:Tex_DefaultTargetFormat = 'pdf'
let g:Tex_CompileRule_pdf = 'pdflatex --synctex=1 -interaction=nonstopmode $*'


Now to do inverse search, what you want to do is open up evince with the .pdf file, open gvim with the file with something like: gvim –servername foo thefile.tex. The –servername argument will let us communicate with that instance of gvim. Now run

evince_vim_dbus.py GVIM foo thefile.pdf thefile.tex


This will keep running and will talk to evince and when you control-click somewhere the script will call the “foo” instance of gvim and tell it to go to the right line. You have to kill this script once you are done. Yeah I know this is kind of ugly, but the way synctex is done in evince is kind of moronic. The idea is I think to make the thing as complicated as possible to satisfy someone’s CS design fetish rather than to make the thing simple and easily usable (such as doing it by calling evince with the right arguments and giving evince a command to execute) … but then no script like this would be needed.

I also have a modified whaw: whaw-jiri-0.1.2.tar.gz. When you run whaw –htile you will get a different cursor, you can left click bunch of windows and then right click and whaw will put the windows side by side. The standard whaw works as well, but the –htile is usable from scripts.

Finally to put it all together I have a script that runs everything for me called buildpdftexwatch (slightly modified version of the script from my homepage) which works as follows (by the way you need zsh installed for the script). You run buildpdftexwatch thefile where thefile doesn’t have any extension. The script will open thefile.tex in gvim and thefile.pdf in evince. If you have the modified whaw it will run it with –htile (otherwise it won’t run whaw). The script watches the .tex file and whenever you save in vim it will rerun pdflatex. (it also runs pdflatex in interactive mode when first invoked before it runs evince actually). It runs pdflatex in noninteractive mode afterwards so that it doesn’t hang. It will notify you of errors by barking (that is if you have ogg123 and the default gnome sound /usr/share/sounds/gnome/default/alerts/bark.ogg installed.

This setup is not perfect. Yeah I know I should probably rewrite the shell script to work in python so that the dbus thing can be done from the script itself. However, evince also sucks so I’d rather just use xpdf, but that does not yet have synctex support. At some point I may be enough annoyed with evince that I will hack xpdf to do synctex (and do it in the simple nondbusy way that will make it easy to work with all kinds of editors). For now … this works good enough.

Update: Make sure to use the latest evince (at least 2.32.0) as older versions do not have synctex support.

Update: GNOME 3 evince breaks the dbus interface and the above python code. (So what’s the advantage of using dbus here? It is total overkill, isn’t documented well (as far as I can find), and breaks from release to release anyway). The least that evince could do is to have command line options so that one does not need to do dbus black magic to make it work. Anyway I had to fix it up and now there are two versions, one for GNOME 3 and one for GNOME 2.32. I also integrated the below comment from Simon.

Update: New braindamage coming (this time) from TexLive 2011 synctex. Apparently we must now insert /./ into the path or synctex will refuse to work. This is wrong on so many levels it is not even funny. That means there are 3 distinct versions of this code with just slightly different semantics. Somebody somewhere should get a smack over the head when a new feature that most people likely won’t ever use will break all existing usage. Certain people should not be allowed to design public facing APIs. Also there might be some change in the way vim does the current filename thing because the script was now getting full path name for the input file, so I had to fix that too. I am not quite sure what happened there though so I am not ready to blame vim. I can’t understand however how else could have the old version have worked before.

Update: New changes in GNOME.  So apparently the API changed again.  Where we got a filename before apparently we now get a uri (which I suppose is more consistent but a break in the API again).  So I updated the code to strip “file://” if it finds it.  Should still work with older evinces, and with new.  I have now tested it with evince 3.8 and TexLive 2012.