{{ message }}

# An Additional MuPDF Window is Created When Doing a Forward Search in a Multi-File LaTeX Project #312

Closed
opened this issue Jan 7, 2016 · 3 comments
Closed

# An Additional MuPDF Window is Created When Doing a Forward Search in a Multi-File LaTeX Project#312

opened this issue Jan 7, 2016 · 3 comments

### gkapfham commented Jan 7, 2016

 Once again, thanks for developing this plugin! I use it on a regular basis. I am currently experiencing an issue where vimtex creates another MuPDF window when I do a forward search in a mutl-file LaTeX document. Here is the version of vim that I am currently using VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 10 2015 17:05:47)  I am currently running Vim and vimtex on the Ubuntu 15.04 operating system. I have created a minimal working example to replicate this issue. First, here are the contents of my .vimrc file: set nocompatible filetype plugin indent on syntax enable set iskeyword+=: set hidden " change the mapleader from \ to , -- this makes it easier to perform compilation in LaTeX let maplocalleader="," let mapleader="," call plug#begin('~/.vim/bundle') Plug 'https://github.com/lervag/vimtex.git', {'for': 'tex'} call plug#end() " Starting to use vim-latex and it needs several configurations to work correctly let g:vimtex_latexmk_options="-pdf -pdflatex='pdflatex -file-line-error -shell-escape -synctex=1'" let g:vimtex_fold_enabled = 0 let g:vimtex_quickfix_mode = 2 let g:vimtex_quickfix_open_on_warning = 1 let g:vimtex_toc_resize = 0 let g:vimtex_toc_hide_help = 1 let g:vimtex_indent_enabled = 1 let g:vimtex_latexmk_enabled = 1 let g:vimtex_latexmk_callback = 1 let g:vimtex_complete_recursive_bib = 0 let g:vimtex_view_method = 'mupdf'  Here are the contents of my .latexmkrc file: $print_type = 'pdf';$pdf_mode = 1; $bibtex_use = 2; push @generated_exts, "cb"; push @generated_exts, "cb2"; push @generated_exts, "spl"; push @generated_exts, "nav"; push @generated_exts, "snm"; push @generated_exts, "tdo"; push @generated_exts, "nmo"; push @generated_exts, "brf"; push @generated_exts, "nlg"; push @generated_exts, "nlo"; push @generated_exts, "nls"; push @generated_exts, "synctex.gz"; push @generated_exts, "tex.latexmain"; push @generated_exts, "run.xml";$latex = 'latex --src-specials %O %S'; $pdflatex = 'pdflatex -file-line-error -synctex=1 -interaction=nonstopmode -shell-escape %O %S'; # If zero, check for a previously running previewer on the same file and update it. If nonzero, always start a new previewer.$new_viewer_always = 0; # How to make the PDF viewer update its display when the PDF file changes. See the man page for a description of each method. $pdf_update_method = 2; # When PDF update method 2 is used, the number of the Unix signal to send$pdf_update_signal = 'SIGHUP'; add_cus_dep('nlo', 'nls', 0, 'nlo2nls'); sub nlo2nls { system("makeindex $_[0].nlo -s nomencl.ist -o$_[0].nls -t $_[0].nlg" ); } # vim: ft=perl  Here is the content of the minimal.tex file: \documentclass{minimal} \begin{document} Hello world first page! \newpage Hello world second page! \newpage \input{sections/first.tex} \end{document}  Note that this file includes a file called first.tex in the sections directory. Here is that file: % vim: ft=tex % !TEX root = minimal.tex Hello world third page!! I am going to write a lot of content now. Does this work??  Now, I will start compilation in the minimal.tex file by running the ,ll command. This correctly displays the MuPDF window and ultimately leads to the following configuration report from vimtex: b:vimtex : minimal pid : 12833 root : '/home/gkapfham/working/writing/minimal' aux : '/home/gkapfham/working/writing/minimal/minimal.aux' log : '/home/gkapfham/working/writing/minimal/minimal.log' out : '/home/gkapfham/working/writing/minimal/minimal.pdf' tex : '/home/gkapfham/working/writing/minimal/minimal.tex' tmp : '/tmp/vJdwNI2/1' cmd_latexmk_compile : 'cd ''/home/gkapfham/working/writing/minimal'' && max_print_line=2000 latexmk -verbose -pdf -pdf -pdflatex=''pdflatex -file-line-error -shell-escape -synctex=1'' -e ''$pdflatex =~ s/ / -file-line-error /'' -pvc -e ''$success_cmd = "\"vim\" --servername VIM9 --remote-expr \"vimtex\#latexmk\#cal lback(1)\""'' -e ''$failure_cmd = "\"vim\" --servername VIM9 --remote-expr \"vimtex\#latexmk\#callback(0)\""'' -e ''$new_viewer_always = "0"'' -e ''$pdf_update _method = "2"'' -e ''$pdf_update_signal = "SIGHUP"'' -e ''$pdf_previewer = "mupdf "'' ''minimal.tex'' >/tmp/vJdwNI2/1 2>&1' base : 'minimal.tex' viewer page : '1' xwin_id : '138412099' class : 'MuPDF' cmd_synctex_view : 'synctex view -i 2:2:''/home/gkapfham/working/writing/minimal/minimal.tex'' -o ''/home/gkapfham/working/writing/minimal/minimal.pdf'' | grep -m1 ''Page:'' | sed ''s/Page://'' | tr -d '' ''' cmd_forward_search : 'xdotool type --window 138412099 "1g"' init : function('16') view : function('17') start : function('18') forward_search : function('19') reverse_search : function('20') latexmk_callback : function('21') latexmk_append_argument : function('22') focus_viewer : function('42_focus_viewer') focus_vim : function('42_focus_vim') xwin_exists : function('42_xwin_exists') xwin_get_id : function('42_xwin_get_id') xwin_send_keys : function('42_xwin_send_keys')  If I run the ,lg command it does indicate that vimtex is "running". Now, if I switch to the buffer that contains the file inside of the sections directory and run ,li again, I see this output: b:vimtex : minimal pid : 12833 root : '/home/gkapfham/working/writing/minimal' aux : '/home/gkapfham/working/writing/minimal/minimal.aux' log : '/home/gkapfham/working/writing/minimal/minimal.log' out : '/home/gkapfham/working/writing/minimal/minimal.pdf' tex : '/home/gkapfham/working/writing/minimal/minimal.tex' tmp : '/tmp/vJdwNI2/1' cmd_latexmk_compile : 'cd ''/home/gkapfham/working/writing/minimal'' && max_print_line=2000 latexmk -verbose -pdf -pdf -pdflatex=''pdflatex -file-line-error -shell-escape -synctex=1'' -e ''$pdflatex =~ s/ / -file-line-error /'' -pvc -e ''$success_cmd = "\"vim\" --servername VIM9 --remote-expr \"vimtex\#latexmk\#cal lback(1)\""'' -e ''$failure_cmd = "\"vim\" --servername VIM9 --remote-expr \"vimtex\#latexmk\#callback(0)\""'' -e ''$new_viewer_always = "0"'' -e ''$pdf_update _method = "2"'' -e ''$pdf_update_signal = "SIGHUP"'' -e ''\$pdf_previewer = "mupdf "'' ''minimal.tex'' >/tmp/vJdwNI2/1 2>&1' base : 'minimal.tex' viewer xwin_id : 0 class : 'MuPDF' init : function('16') view : function('17') start : function('18') forward_search : function('19') reverse_search : function('20') latexmk_callback : function('21') latexmk_append_argument : function('22') focus_viewer : function('42_focus_viewer') focus_vim : function('42_focus_vim') xwin_exists : function('42_xwin_exists') xwin_get_id : function('42_xwin_get_id') xwin_send_keys : function('42_xwin_send_keys')  It is important to note that there is no xwin_id for this buffer. As you would expect, if you now run the forward search command with an ,lv then it will start another MuPDF window. My understanding is that this is not the specified behavior; instead, it should "zoom" over to the existing MuPDF window that was created when I first ran the compilation step. But, it is important to note that running this command will start the new MuPDF window on the correct page of the document. Also, it is relevant to note that vimtex never crashes throughout this process. Can you investigate this issue and see if there is a problem in my configuration of vimtex or, alternatively, in the source code of vimtex? I should note that I have discovered a workaround that allows me to temporarily handle this problem. Once I have entered the first.tex file, if I stop compilation and the re-start compilation, the vimtex debugging information will indicate the same xwin_id as I saw when running the debugging command in the minimal.tex file. Now, if I perform the ,lv command the forward search will work correctly and I will "zoom" to the correct page of the pdf in the existing MuPDF window. Again, thanks for taking the time to investigate this issue. I understand that you are very busy with other work and that you can only maintain vimtex in your spare time. But, if possible, I look forward to soon hearing your response!
closed this in  db13756  Jan 7, 2016

### lervag commented Jan 7, 2016

 Thanks for the thorough description. In the email you also mentioned that this worked earlier. I thought it did, and I guess I never noticed this because I haven't worked on multiple file projects for some time. In any case, I used git bisect and found the problem quite quickly. Thanks!

### gkapfham commented May 25, 2016 • edited

 Hello again @lervag! Please excuse the very long delay in confirming that your fix is now working correctly. As always, thanks for all of your hard work in developing this very useful plugin — I gladly use it on a very regular basis!

### lervag commented May 26, 2016

 No problem, and thanks for the kind words!