Setting up forward/inverse Synctex search with supplementary tex files

[YanniPapandreou]

Hi,

First of all thank you for creating this plugin, I was struggling to set up synctex on neovim properly and this just works!

I am using the default pdf reader Sioyek and synctex works in both forward and reverse directions when I am editing a single tex file. I am having issues however when I have a more complicated tex document with supplementary tex files. To be more clear I have a project structure like follows:

 doc
├──  chapters
│  ├──  chapter_1
│  │  ├──  intro.tex
│  │  └──  summary.tex
│  └──  chapter_2
│     ├──  intro.tex
│     └──  summary.tex
└──  main.tex

When I open main.tex in neovim and toggle knap autopreview with <F7> the document opens and I can use both forward and reverse search. However, if I go to a part of the pdf in Sioyek which was included in the main document via \input{chapters/chapter_1/intro.tex} and try to right-click to do an inverse search it does not jump to the appropriate file and instead neovim just prints something like:

jump spot at line 5 col 0 in /path/to/docs/./chapters/chatper_1/intro.tex

I cannot understand how to fix this from the docs. Also if I open the file chapters/chapter_1/intro.tex in neovim after launching the autopreview from main.tex and I press <F7> again then I can successfully use reverse search by pressing <F4> in Sioyek and right-clicking. However, now I cannot forward search from the supplementary file using <F8>, neovim prints out Viewer not currently active.

I have put on the top of my supplementary file % TeX root = ../../main.tex.

Is there a way to fix these issues?

These are my settings for knap:

local gknapsettings = {
  texoutputext = "pdf",
  textopdf = "pdflatex -interaction=batchmode -halt-on-error -synctex=1 %docroot%",
  -- textopdf = "pdflatex -jobname \"$(basename -s .pdf %outputfile%)\" -halt-on-error",
  textopdfviewerlaunch = "/home/yanni/Applications/Sioyek-x86_64_2df5964a856fc1f662dd4663896aeb21.AppImage --inverse-search 'nvim --headless -es --cmd \"lua require('\"'\"'knaphelper'\"'\"').relayjump('\"'\"'%servername%'\"'\"','\"'\"'%1'\"'\"',%2,%3)\"' --reuse-instance %outputfile%",
  textopdfviewerrefresh = "none",
  textopdfforwardjump = "/home/yanni/Applications/Sioyek-x86_64_2df5964a856fc1f662dd4663896aeb21.AppImage --inverse-search 'nvim --headless -es --cmd \"lua require('\"'\"'knaphelper'\"'\"').relayjump('\"'\"'%servername%'\"'\"','\"'\"'%1'\"'\"',%2,%3)\"' --reuse-instance --forward-search-file %srcfile% --forward-search-line %line% %outputfile%",
  textopdfshorterror = "A=%outputfile% ; LOGFILE=\"${A%.pdf}.log\" ; rubber-info \"$LOGFILE\" 2>&1 | head -n 1",
  -- textopdfbufferasstdin = true,
  delay = 250
}

vim.g.knap_settings = gknapsettings

and my keymaps are the default ones suggested:

-- F5 processes the document once, and refreshes the view
vim.keymap.set('i','<F5>', function() require("knap").process_once() end)
vim.keymap.set('v','<F5>', function() require("knap").process_once() end)
vim.keymap.set('n','<F5>', function() require("knap").process_once() end)

-- F6 closes the viewer application, and allows settings to be reset
vim.keymap.set('i','<F6>', function() require("knap").close_viewer() end)
vim.keymap.set('v','<F6>', function() require("knap").close_viewer() end)
vim.keymap.set('n','<F6>', function() require("knap").close_viewer() end)

-- F7 toggles the auto-processing on and off
vim.keymap.set('i','<F7>', function() require("knap").toggle_autopreviewing() end)
vim.keymap.set('v','<F7>', function() require("knap").toggle_autopreviewing() end)
vim.keymap.set('n','<F7>', function() require("knap").toggle_autopreviewing() end)

-- F8 invokes a SyncTeX forward search, or similar, where appropriate
vim.keymap.set('i','<F8>', function() require("knap").forward_jump() end)
vim.keymap.set('v','<F8>', function() require("knap").forward_jump() end)
vim.keymap.set('n','<F8>', function() require("knap").forward_jump() end)

[frabjous]

Thanks for your feedback.

It's not that anything is broken in your config, it's just that what you're asking for — full synctex support with supplementary files – is not something I've implemented, and while it seems like a desirable thing, and probably worth implementing, I'd have to give more thought about how to do so.

Part of this is personal preference. I want to be in charge of which files are open in Neovim; I don't want it unexpectedly opening some LaTeX package god-knows-where on my file system, which just happened to be listed in the synctex file for some reason; I'd rather it just tell me where to look and I can make the choice about whether to open it or not, so that's why I've implemented it the way I have.

But I could certainly see the use, especially if the file is already one I have open anyway, of having it focus on that tab or window and jump to the appropriate line. I don't think that would be super hard to implement, and may try to do so when I get a chance.

Allowing forward jumps from the files that aren't the one from which you launched the plugin is probably a little more work to implement; it would require the plugin knowing which files you're editing connect with each other in a bidirectional way. Either you'd have to have not just TeX root = ... as a "magic' comment, but some way to officially indicate "sibling" or "child" documents. This might require more substantial changes to the plugin to implement well, but is probably doable too.

I will definitely take these suggestions on board and think about them. Unfortunately I'm going to be insanely busy at least for the next two months, and quite possibly longer, so it's unlikely I'll get to working on this before then. But if you know any lua, I'd be more than willing to consider pull requests.

[pako-github]

I forked the project and added multifile support for inverse SyncTex search. I tested it only for Sioyek and it works. Since I have to check the other viewers and also the forward search, I hesitate to make a pull request yet.

[frabjous]

Thanks! I look forward to seeing what you come up with.

Assuming you mainly just edited the "jump()" function, it's hard to believe the choice of viewer would make much of a difference, but yes, it probably is worth testing as many as is convenient.

When my schedule frees up, I'd be happy to help you test, but of course I'd need to see your code one way or another.

The forward searches … again, this might be trickier. I guess the easiest way would be for the plugin to store a global variable with full path names of root documents and which open buffers' previews they attach to, and to have the forward search function compare the root for the current document to that list to find what preview it should interact with. Maybe — though implementing this is what I think would take the most work — the entire plugin should organize itself around root documents rather than individual buffers, and attach all its variables to those rather than the active buffer. That might require a lot of rewriting. But maybe that amount of refactoring isn't necessary.

Definitely don't feel like you need to include that in your pull request if you'd rather treat the two issues piecemeal, however.

[pako-github]

Yes you are right, I just edited the jump() function. But I encoutered today a problem: What I did was just a quick hack to implement the inverse search by loading the file (coming from SyncTex from Sioyek) into a buffer and then I send the buffer to the current window in nvim. But then the knap routine does not recognize this new file (of course), so I have to start the routine again with this file, but withtout starting a new browser (I guess?)

If you have a suggestion, feel free to tell me 😃

Btw @frabjous : Thanks very much for your clean code and your very helpful comments in the code! The fork is available under https://github.com/pako-github/knap

[frabjous]

I'll take a look when I get a chance, but I suppose the fix for the issue of the new buffer not being attached to the preview would follow naturally from whatever changes we would make to allow forward searches from supplementary files, since both would involve making the plugin recognize when two different buffers shared a root document.

[YanniPapandreou]

Thanks @pako-github and @frabjous for sharing! I am quite new to Lua so not sure how much help I will be right now.

[pako-github]

I'll take a look when I get a chance, but I suppose the fix for the issue of the new buffer not being attached to the preview would follow naturally from whatever changes we would make to allow forward searches from supplementary files, since both would involve making the plugin recognize when two different buffers shared a root document.

But this sounds feasible whenever the root document is determined. Since then you can parse the root document to build the project tree. If time permits I'll have a look at it again.