Zathura backward search: bug with multi-file projects

[psvenk]

Problem

The SyncTeX support for Zathura is excellent out of the box, but I noticed that the backward search command line is hard-coded to use --remote-expr to call vimtex#view#reverse_goto:

vimtex/autoload/vimtex/view/zathura.vim

Lines 38 to 41 in 078292e

	let l:cmd .= ' -x "' . g:vimtex_compiler_progname
	\ . ' --servername ' . v:servername
	\ . ' --remote-expr '
	\ . '\"vimtex#view#reverse_goto(%{line}, ''%{input}'')\""'

This function works well in single-file projects, but I noticed a few problems when switching files in multi-file projects. Specifically, consider the case that a project has files a.tex and b.tex, my Vim currently has a.tex open, and I perform a reverse search from a place in the PDF that corresponds to b.tex line 50.

• If a.tex has unsaved changes, then VimTeX focuses a.tex line 50. This seems to be because the silent edit fails here:
  

  vimtex/autoload/vimtex/view.vim

  Lines 74 to 77 in 078292e

  	" Open file if necessary
  	if !bufexists(l:file)
  	if filereadable(l:file)
  	execute 'silent edit' l:file

• If a.tex does not have unsaved changes, then b.tex takes over the buffer where I was editing a.tex. While this may be desirable behavior for other users, I would prefer that b.tex open in a new tab page.

Suggested solutions/workarounds

I suppose that the first bullet point is a bug and should be fixed globally, but that the second bullet point hinges on subjective preferences. So, I propose that the first part be fixed e.g. by splitting the window, which is what Vim's --remote argument does. To address the tab page issue, I think it would be a good idea to make the behavior configurable.

Alternatively, the use of --remote-expr (as opposed to --remote or --remote-tab) could be made configurable. The stopgap solution that I am using right now is changing the hard-coded --remote-expr to use --remote-tab, and this seems to work fine.

My stopgap solution

diff --git a/autoload/vimtex/view/zathura.vim b/autoload/vimtex/view/zathura.vim
index 95235783..ec17b141 100644
--- a/autoload/vimtex/view/zathura.vim
+++ b/autoload/vimtex/view/zathura.vim
@@ -37,8 +37,7 @@ function! s:zathura.start(outfile) dict abort " {{{1
   if self.has_synctex
     let l:cmd .= ' -x "' . g:vimtex_compiler_progname
           \ . ' --servername ' . v:servername
-          \ . ' --remote-expr '
-          \ .     '\"vimtex#view#reverse_goto(%{line}, ''%{input}'')\""'
+          \ . ' --remote-tab +\%{line} \%{input}\"'
     if g:vimtex_view_forward_search_on_start
       let l:cmd .= ' --synctex-forward '
             \ .  line('.')
@@ -80,7 +79,7 @@ function! s:zathura.latexmk_append_argument() dict abort " {{{1
     if self.has_synctex
       let zathura .= ' -x \"' . g:vimtex_compiler_progname
           \ . ' --servername ' . v:servername
-          \ . ' --remote +\%{line} \%{input}\" \%S'
+          \ . ' --remote-tab +\%{line} \%{input}\" \%S'
     endif
 
     let cmd  = vimtex#compiler#latexmk#wrap_option('new_viewer_always', '0')

I suppose that one could also work around this by using the general viewer and configuring everything manually, but this has obvious downsides.

Miscellany

Additionally, I noticed that --remote and not --remote-expr is used later in the same file, in s:zathura.latexmk_append_argument(). Is there a reason for this? Apologies if this (or anything else in this issue) has already been addressed elsewhere.

vimtex/autoload/vimtex/view/zathura.vim

Lines 79 to 84 in 078292e

	let zathura = 'zathura ' . g:vimtex_view_zathura_options
	if self.has_synctex
	let zathura .= ' -x \"' . g:vimtex_compiler_progname
	\ . ' --servername ' . v:servername
	\ . ' --remote +\%{line} \%{input}\" \%S'
	endif

[lervag]

..., but I noticed that the backward search command line is hard-coded to use --remote-expr to call vimtex#view#reverse_goto

Yes.

• If a.tex has unsaved changes, then VimTeX focuses a.tex line 50. This seems to be because the silent edit fails here

I assume it would not fail if you use set hidden - can you test and confirm? In any case, I agree this is bad and I've tried to fix it by assuring to fail gracefully.

• If a.tex does not have unsaved changes, then b.tex takes over the buffer where I was editing a.tex. While this may be desirable behavior for other users, I would prefer that b.tex open in a new tab page.

... To address the tab page issue, I think it would be a good idea to make the behavior configurable.

Ok. But we need to consider how such configuration would look.

Alternatively, the use of --remote-expr (as opposed to --remote or --remote-tab) could be made configurable. The stopgap solution that I am using right now is changing the hard-coded --remote-expr to use --remote-tab, and this seems to work fine.

So, one possibility would be to allow to change between variants of --remote*.

" The default would be
let g:vimtex_view_zathura_remote = 'expr'

" Now you could easily change to this
let g:vimtex_view_zathura_remote = 'tab'

Another option would be to allow customizing the entire reverse_goto option. E.g.

" The default would be
let g:vimtex_view_zathura_reverse_goto =
      \ '--remote-expr \"vimtex#view#reverse_goto(%{line}, ''%{input}'')\"'

" Now you could easily change to this
let g:vimtex_view_zathura_reverse_goto =
      \ '--remote-tab \"vimtex#view#reverse_goto(%{line}, ''%{input}'')\"'

Additionally, I noticed that --remote and not --remote-expr is used later in the same file, in s:zathura.latexmk_append_argument(). Is there a reason for this?

Yes - in this case, we are passing a command line to latexmk to start Zathura for us, and I was never able to figure out the proper escaping to make the more "advanced" version work. But the simpler --remote version works.

Apologies if this (or anything else in this issue) has already been addressed elsewhere.

No, I think this is new - no need to apologize!

[psvenk]

I assume it would not fail if you use set hidden - can you test and confirm? In any case, I agree this is bad and I've tried to fix it by assuring to fail gracefully.

Using set hidden does open the right file. Thank you for making it log the failure instead of failing silently in the nohidden case. However, I prefer nohidden because it is easy to lose track of a file with unsaved changes if it gets hidden.

Ok. But we need to consider how such configuration would look.

One way could be that the command edit could be configurable by the use of a variable (something along the lines of g:vimtex_view_zathura_edit_command? Or would this generalize beyond Zathura?):

" view.vim in VimTeX
execute g:vimtex_view_zathura_edit_command l:file

" The default would be
let g:vimtex_view_zathura_edit_command = 'edit'

" Now you could easily change to this
let g:vimtex_view_zathura_edit_command = 'tabedit'

Setting this variable to split would emulate the behavior of --remote, and setting it to tabedit would emulate the behavior of --remote-tab. The default value of edit would be the status quo: the file is opened if and only if there are no unsaved changes in the current buffer or hidden is set; otherwise, an error is thrown.

Alternatively, the syntax of this variable could be changed to a full Vim command line with %s for the file name, enabling things like the following:

" view.vim in VimTeX
execute printf(g:vimtex_view_zathura_edit_command, l:file)

" The default would be
let g:vimtex_view_zathura_edit_command = 'edit %s'

" Now you could easily change to this
let g:vimtex_view_zathura_edit_command = 'call MyFunc(''%s'')'

So, one possibility would be to allow to change between variants of --remote*.

" The default would be
let g:vimtex_view_zathura_remote = 'expr'

" Now you could easily change to this
let g:vimtex_view_zathura_remote = 'tab'

… Another option would be to allow customizing the entire reverse_goto option.

Note that the syntax for --remote-tab is akin to that of --remote (à la latexmk command line), so we would need to deal with the --remote and --remote-tab cases separately from the --remote-expr case. In any event, I don't see a use case for this sort of configuration option if we introduce a configurable g:vimtex_view_zathura_edit_command; it would encompass the --remote and --remote-tab cases via split and tabedit and also allow for custom expressions.

[lervag]

Using set hidden does open the right file. Thank you for making it log the failure instead of failing silently in the nohidden case. However, I prefer nohidden because it is easy to lose track of a file with unsaved changes if it gets hidden.

I'll not argue preferences, of course, although I would expect your preference here to be quite uncommon. :)

Ok. But we need to consider how such configuration would look.

One way could be that the command edit could be configurable by the use of a variable ...

Do you think this would resolve your entire request? If so, then I think it is a good idea. As this is actually not purely related to Zathura, I would propose the following configuration:

let g:vimtex_view_reverse_search_edit_cmd = 'edit'
" Allowed values are any values that can be used in place of 'edit'

Alternatively, the syntax of this variable could be changed to a full Vim command line with %s for the file name, enabling things like the following:

Yes, that's also a nice idea. The question is if the extra flexibility is really useful for anyone and worth the complexity cost. There's also the even VimtexEventViewReverse that can be used as semi-relevant hook here, already.

[psvenk]

One way could be that the command edit could be configurable by the use of a variable ...

Do you think this would resolve your entire request? If so, then I think it is a good idea. As this is actually not purely related to Zathura, I would propose the following configuration:

let g:vimtex_view_reverse_search_edit_cmd = 'edit'
" Allowed values are any values that can be used in place of 'edit'

Yes, this sounds like a good resolution. I can work on a fix and open a pull request. Thanks for all of your help!

[lervag]

Yes, this sounds like a good resolution. I can work on a fix and open a pull request. Thanks for all of your help!

Great! Happy to help, and glad to receive PR contributions!

I'll close this issue; let's continue the discussion in #2135.