Implement SumatraPDF viewer with forward (and possibly backward?) search

[lervag]

I've just generalized my implementation of the pdf view commands, see view.vim. I've mostly kept the old functionality as a default through a latex#view#general() function, and I've added mupdf as a viewer with forward search through use of xdotools and synctex.

The new interface should make it relatively easy to implement a view function for SumatraPDF that supports forward search. One could also implement functionality for backward search. However, since I don't use windows and SumatraPDF, I won't implement this functionality myself. I will accept pull requests, though.

@xerron @Konfekt @d125q

[Konfekt]

Ok, in the meanwhile, changing the ancient options to

  let g:latex_view_general_viewer='SumatraPDF'
  let g:latex_view_general_options='-reuse-instance -inverse-search '.
  \    '"gvim --servername '.v:servername.' +\%l -c zvzz \"\%f\""'

works fine. Also, it seems you are referring to inverse search. The terminology couldn't be worse. That's why I added if its Viewer -> Editor or vice versa in the documentation.

What stroke me in you mupdf example: Even if it is exclusive for mupdf, should the cmd not be customizable? For example, if mupdf is not in $PATH?

[xerron]

Why are you implementing functionality for a specific viewer ?, not understand. @lervag What has MuPDF special?

[d125q]

I opened a pull request for SumatraPDF. I really like how this is being done.

However, I have one doubt. Why are we allowing users to add arguments to :VimLatexView? This is just a way to have people shoot themselves in the foot. For one, MuPDF and SumatraPDF ignore them, and both have forward searching configured by default.

I will also write a guide on how to nicely set up inverse searching from within SumatraPDF. It's very simple -- just add editexisting.vim from $VIMRUNTIME/macros as a plugin (you can have it work for .tex files only, but I think it's very sensible to have it work with all files), and have path\to\gvim.exe "%f" +%l as an inverse search command line from within SumatraPDF.

A question: when a compilation initiated with <Leader>ll is finished, SumatraPDF is automatically opened. Is this done by latexmk or by this plugin?

Also, Karl, please consider adding modelines that indicate that spaces of size 2 should be used for indentation. I think it'd help in keeping a consistent style.

[lervag]

@Konfekt Thanks for the clarification of the confusing terms (forward and inverse search). To check if I understand correctly: Forward search is pdf -> vim, and inverse search is vim -> pdf?

@Konfekt Regarding the cmd, I was actually thinking to keep separate functions for each viewer. My thought was to allow support for as many viewers as possible, including okular, evince, SumatraPDF, and others. For those that are OS specific and not available on Linux I will not be able to do the implementation myself, but I will try to assist. For Linux viewers I may implement support for more viewers when I get the time.

@xerron MuPDF is the pdf viewer I use personally. I've found a nice hack that allows me search from vim to viewer (inverse search?) for MuPDF, and I've implemented this. I will implement functionality for other viewers with time. The point of this is to make it easier for users to get forward and inverse search functionality (and possibly other functionality) based on their viewer of choice.

@d125q Thanks!The reason we allow arguments at the moment is historical, and I was tempted to remove it already in the last commit. I've kept it for now because I know someone was using this to implement forward and/or inverse search.

@d125q When a compilation is initiated with <leader>ll, latexmk is started in the background with the -pvc option (see manual, pvc is short for preview continuously), which implies that it will compile the document continuously after each save, and open the viewer after first successful compilation. The viewer will be updated after successive successful compilations automatically.

@d125q Thanks for the suggestion about modeline settings. Since the plugin has started to get some traction it seems very sensible to set some standards for syntax style.

[lervag]

I'll close the issue due to #80, but let us please continue the discussion.

[d125q]

Regarding the arguments -- there is now g:latex_view_general_options and similar, which can be used for that purpose (I think).

I suppose I should read more about latexmk. Thank you for all your work!

By the way, forward searching is editor --> viewer, inverse searching is viewer --> editor; your original wording was correct.

[Konfekt]

@d125q True. Messed up there.

@lervag Still, for those who use mupdf and do not put it into the PATH, it might be helpful to set the viewer path without having to dig into the source code. Looking at your mupdf function, there's little that would work on windows, so in this case the the general viewer options seems sufficient.

Of course, they could be made a sumatrapdf function but this would copy paste a lot of your mupdf viewer function and create a lot of redundancy. So best would be a sumatra pdf function that calls the general viewer function with the above parameters for Sumatra PDF.

To sum up, how about a function that takes the sumatra pdf defaults for the general viewer function, and respects g:latex_view_sumatra_viewer or g:latex_sumatra_viewer_cmd_options.

[lervag]

@d125q Yes, I agree. I'll look into a way to make the examples for forward/backward search in the documentation work without passing arguments.

@Konfekt I think most people who use mupdf will have it in their PATH. If anyone actually does have a problem with this, I'll consider changing after an issue have been opened. Until then I'll consider this a non-issue.

When it comes to redundancy, I agree that the the moment there might be some redundancy. However, I think I want to accept that for now. The reason is that I think it is easier to generalize when the pattern is clearer. At the moment I think it seems like a lot of the viewers have different ways of doing things, and so by making reduntant and explicit code for each viewer we will get code that works and that does exactly what we want. After we have several viewers implemented I think it will be easier to see the patterns that allow for a better and more general code.

In the mean time, I want to both allow and encourage redundant code for the viewers.

[Konfekt]

Ok, it just stroke me that The first line that checks the existence of the PDF seems universal.

Other than that I agree. Seems a good strategy to wait for an emerging pattern.

[lervag]

Great, then we agree. I hope that I can get some progress on the implementation in the following days.