Closed Liampor closed 1 year ago
I have a similar setup as yours. I do not encounter this error. (I use VIM and not neovim though). Infact, I do not have any pdf viewer setting in my .vimrc at all. Have you tried setting Sumatra PDF as the default application to open pdf files in native Windows? I know that Acrobat PDF does not work well with VimTeX and the latter tends to be the default application to open pdf files in Windows.
I have a similar setup as yours. I do not encounter this error. (I use VIM and not neovim though). Infact, I do not have any pdf viewer setting in my .vimrc at all. Have you tried setting Sumatra PDF as the default application to open pdf files in native Windows? I know that Acrobat PDF does not work well with VimTeX and the latter tends to be the default application to open pdf files in Windows.
thanks for your reply, sumatraPDF is always the default pdf viewer in Windows. But the problem is still there
Hmm... I am not a great trouble shooter in this regard. WSL1 is rather old. Is updating to WSL2 a possibility? https://learn.microsoft.com/en-us/windows/wsl/compare-versions
Can you open a pdf file from within WSL by the following command?
/mnt/d/Project$ cmd.exe /C start main.pdf
Does this open up main.pdf using SumatraPDF and other variants of this command from different directories and providing relative addressing? This command works at my end as I described and if it doesn't at your end that may be a guide to troubleshoot.
Hmm... I am not a great trouble shooter in this regard. WSL1 is rather old. Is updating to WSL2 a possibility? https://learn.microsoft.com/en-us/windows/wsl/compare-versions
Can you open a pdf file from within WSL by the following command?
/mnt/d/Project$ cmd.exe /C start main.pdf
Does this open up main.pdf using SumatraPDF and other variants of this command from different directories and providing relative addressing? This command works at my end as I described and if it doesn't at your end that may be a guide to troubleshoot.
WSL1 is rather old. Is updating to WSL2 a possibility?
I would like to stay in WSL1 for better IO performance
/mnt/d/Project$ cmd.exe /C start main.pdf
-- will return permission error.
But when I cd to /mnt/d/Project
and then run
cmd /C start main.pdf
this could open up main.pdf without any problem
Another thing is, if the project is created in WSL1 it self (stored in WSL1 space), it also works fine
Related Settings:
vim.g['vimtex_view_general_viewer'] = 'SumatraPDF.exe' vim.cmd([[let g:vimtex_view_general_options \ = '-reuse-instance -forward-search @tex @line @pdf' \ . ' -inverse-search "' . exepath(v:progpath) \ . ' --servername ' . v:servername \ . ' --remote-send \"^<C-\^>^<C-n^>' \ . ':execute ''drop '' . fnameescape(''\%f'')^<CR^>' \ . ':\%l^<CR^>:normal\! zzzv^<CR^>' \ . ':call remote_foreground('''.v:servername.''')^<CR^>^<CR^>\""']])
I would suggest the following changes to your options (similar to what is suggested in the docs at :help vimtex-view-sumatrapdf
):
vim.g.vimtex_view_general_viewer = 'SumatraPDF.exe'
vim.g.vimtex_view_general_options = '-reuse-instance -forward-search @tex @line @pdf'
To configure inverse search, you should instead configure from within SumatraPDF (again, as described in the docs).
SumtraPDF cannot load the generated PDF error, shows the error, "loading file:
D:/mnt/d/Project/main.pdf
"
Can you show a screenshot of the error message?
From my understanding, the path is wrong, there shouldn't be
/mnt/d
there
The path is not wrong. If you are in WSL, then the full absolute path is /mnt/d/Project/main.pdf
. What happens if you do this:
Start WSL1. It should open a bash shell.
Run nvim /mnt/d/Project/main.tex
. Does it open the main.tex
file as expected?
Exit Neovim, then run SumatraPDF.exe /mnt/d/Project/main.pdf
. Does it work?
I would like to stay in WSL1 for better IO performance
I don't think that's a very good reason, except for very specific purposes. LaTeX is not one of them, I believe. At least, I've not heard anyone complain about performance related issues using LaTeX and VimTeX in WSL2.
Related Settings:
vim.g['vimtex_view_general_viewer'] = 'SumatraPDF.exe' vim.cmd([[let g:vimtex_view_general_options \ = '-reuse-instance -forward-search @tex @line @pdf' \ . ' -inverse-search "' . exepath(v:progpath) \ . ' --servername ' . v:servername \ . ' --remote-send \"^<C-\^>^<C-n^>' \ . ':execute ''drop '' . fnameescape(''\%f'')^<CR^>' \ . ':\%l^<CR^>:normal\! zzzv^<CR^>' \ . ':call remote_foreground('''.v:servername.''')^<CR^>^<CR^>\""']])
I would suggest the following changes to your options (similar to what is suggested in the docs at
:help vimtex-view-sumatrapdf
):vim.g.vimtex_view_general_viewer = 'SumatraPDF.exe' vim.g.vimtex_view_general_options = '-reuse-instance -forward-search @tex @line @pdf'
To configure inverse search, you should instead configure from within SumatraPDF (again, as described in the docs).
SumtraPDF cannot load the generated PDF error, shows the error, "loading file:
D:/mnt/d/Project/main.pdf
"Can you show a screenshot of the error message?
From my understanding, the path is wrong, there shouldn't be
/mnt/d
thereThe path is not wrong. If you are in WSL, then the full absolute path is
/mnt/d/Project/main.pdf
. What happens if you do this:
- Start WSL1. It should open a bash shell.
- Run
nvim /mnt/d/Project/main.tex
. Does it open themain.tex
file as expected?- Exit Neovim, then run
SumatraPDF.exe /mnt/d/Project/main.pdf
. Does it work?
vim.g.vimtex_view_general_viewer = 'SumatraPDF.exe'
vim.g.vimtex_view_general_options = '-reuse-instance -forward-search @tex @line @pdf'
Same issue,
screenshot is here
as you can see, a "mixed" path is here, "
D:\
" stay together with "/mnt/d
"
I could only understand either "D:\project\main.pdf
" or "/mnt/d/main.pdf
", not a combined with them
Regarding your questions:
Run nvim /mnt/d/Project/main.tex
. Does it open the main.tex file as expected?
Yes
Exit Neovim, then run SumatraPDF.exe /mnt/d/Project/main.pdf.
Does it work?
No, report the same loading error with "mixed" path
Hmm. That's interesting and seems like a hard problem. The problem here is that you are using neovim inside a Bash shell in WSL, in which case VimTeX "believes" it is on Linux and behaves accordingly. This is usually fine, but in this specific case we are passing a file argument to SumatraPDF, which is a Windows applications, and thus the absolute path is not recognized because we are also crossing the WSL boundary.
I've not encountered this before, so before looking into any specific solution, I'm curious if this may be already resolved on WSL2 in the underlying interface between WSL and Windows. @TryerGit: Do you have WSL2 and SumatraPDF both available; if so, would you be willing to try and duplicate this issue? It should be quite easy:
/mnt/c/tmp/test.pdf
.SumatraPDF.exe /mnt/c/tmp/test.pdf
from the WSL2 shell.Hmm. That's interesting and seems like a hard problem. The problem here is that you are using neovim inside a Bash shell in WSL, in which case VimTeX "believes" it is on Linux and behaves accordingly. This is usually fine, but in this specific case we are passing a file argument to SumatraPDF, which is a Windows applications, and thus the absolute path is not recognized because we are also crossing the WSL boundary.
I've not encountered this before, so before looking into any specific solution, I'm curious if this may be already resolved on WSL2 in the underlying interface between WSL and Windows. @TryerGit: Do you have WSL2 and SumatraPDF both available; if so, would you be willing to try and duplicate this issue? It should be quite easy:
- Open a WSL2 shell (bash or zsh).
- Create or copy some minimal pdf file and put it at some location, say
/mnt/c/tmp/test.pdf
.- Check what happens if you do
SumatraPDF.exe /mnt/c/tmp/test.pdf
from the WSL2 shell.
Is it possible do some tricks in vimtex. For examle I could open the pdf right in shell with
sumatrapdf.exe $(wslpath -m /mnt/d/project/main.pdf)
the wslpath -m
command first converts the path to windows style -> D:\project\main.pdf
, then call the sumatrapdf to loading
then I could create a function in bash, actually in zsh
function sumatraOpen() {
sumatrapdf.exe $(wslpath -m $1)
}
After that I could use sumatraOpen /mnt/d/project/main.pdf
in shell
But If I tried to set vim.g['vimtex_view_general_viewer'] = 'sumatraOpen'
, it will return error:
VimTeX: Generic viewer is not executable!
- Viewer: sumatraOpen
- Executable: sumatraOpen
- Please see :h g:vimtex_view_general_viewer
But I still believe there is some trick to overcome my problem
- Open a WSL2 shell (bash or zsh).
- Create or copy some minimal pdf file and put it at some location, say
/mnt/c/tmp/test.pdf
.- Check what happens if you do
SumatraPDF.exe /mnt/c/tmp/test.pdf
from the WSL2 shell.
I got some interesting results:
:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$
This is the folder where in Windows (via WSL) SumatraPDF.exe
resides.
Typing :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$SumatraPDF.exe
returns SumatraPDF.exe: command not found
Typing as if in Linux : Typing :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$./SumatraPDF.exe
opens up SumatraPDF app with no file loaded.
:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe /mnt/e/GoogleDrive/CVs/CV.pdf
gives me the exact same error as reported by @Liampor
I get: Error loading C:\mnt\e\...\CV.pdf
in the SumatraPDF application window which opens but does not load the file. Of course the file cannot be loaded because for some reason, C:\
gets added to mnt\e\
which gives rise to a garbage nonexistent and unrecognizable folder path.
I further tried: :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$cmd.exe /C /start /mnt/e/GoogleDrive/CVs/CV.pdf
This gives error: Invalid switch - "/mnt".
Then, I navigated to E:\GoogleDrive\CVs\ in Windows and opened up WSL here. This gives me:
:/mnt/e/GoogleDrive/CVs$
Now issuing :/mnt/e/GoogleDrive/CVs$cmd.exe /C start CV.pdf
opens up SumatraPDF and properly displays CV.pdf
Then, I wanted to test if this across folder problem persists in native windows. It did not. For e.g., I issued cmd.exe
in Windows. This opens up a dos command prompt : C:\Users\TryerGit>
Here, I tried to start
the same pdf file across folders.
C:\Users\TryerGit>start e:\GoogleDrive\CVs\CV.pdf
This works just fine and the CV.pdf
file opens up in SumatraPDF app.
So, it seems that the "problem" is not because of which version of is being used -- WSL1 or WSL2, nor does the problem seem to be in VimTeX. It seems that WSL opening of native Windows files cannot happen across folders or else it cannot work with absolute paths. It only works if the file resides in the current folder or possibly with relative addressing. I am not sure about @Liampor 's workflow. The above tests are news to me as well and somewhat unexpected -- I expected WSL to be able to handle opening files fine across folders -- but my workflow with SumatraPDF has been working fine thus far (knock on all wood) since I have \ll
open up the pdf file via continuous compilation where the pdf gets created in the same folder as the .tex
file somehow. I do not have any pdf reader settings in my vimrc.
ETA: What finally worked was the following:
:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ cmd.exe /C start "e:\GoogleDrive\CVs\CV.pdf"
This may hold the clue -- i.e., the path to be specified via WSL to a Windows file should following Windows naming convention.
The above opened up SumatraPDF and the pdf file just fine.
Below also works: :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ cmd.exe /C start "e:/GoogleDrive/CVs/CV.pdf"
:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe "e:/GoogleDrive/CVs/CV.pdf"
works, as does,
:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe e:/GoogleDrive/CVs/CV.pdf
but the following does not work:
:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe e:\GoogleDrive\CVs\CV.pdf
-- this gives error Error loading E:\GoogleDriveCVsCV.pdf
because of backslash \
escape character? The following works:
:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe e:\GoogleDrive\\CVs\\CV.pdf
Is it possible do some tricks in vimtex. For examle I could open the pdf right in shell with
sumatrapdf.exe $(wslpath -m /mnt/d/project/main.pdf)
the
wslpath -m
command first converts the path to windows style ->D:\project\main.pdf
, then call the sumatrapdf to loadingthen I could create a function in bash, actually in zsh …
Ah, yes, I believe this is the most elegant and simple solution. I.e., not to change anything in VimTeX, but instead to make a simple wrapper script. It should be a script, not a function. E.g., ensure you have e.g. ~/.local/bin
in your $PATH
in your .zshrc
, then create a file like ~/.local/bin/sumatraOpen
:
#!/usr/bin/env bash
sumatrapdf.exe $(wslpath -m $1)
Notice, though, it must be slightly more complicated. I can help, but I don't have the time right now. The point is, you need to only wrap the path, not the other arguments.
Also, thanks for the input, @TryerGit! I believe @Liampor already found a proper way to solve this with the wslpath
utliity, and that the best way to proceed is to use a wrapper script on the user side.
@Liampor Notice that with the earlier proposed settings (except changing the viewer command), VimTeX will execute the following command:
SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 '/mnt/d/Project/main.pdf'
So, the wrapper script must recognize the paths (both of them, probably), and wrap these with wslpath
. It should not be too hard (e.g., you could start by assuming there are 5 arguments and wrap argument number 3 and 5).
-reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 '/mnt/d/Project/main.pdf'
Sorry for the late response, as your suggestions, I have created a zsh-script called open-sumatra.sh
in ~/.local/bin
defined as
#!/bin/zsh
new_arg=() # ceate arguments array
for arg ($@){
if [[ "$arg" == /mnt/* ]] {
# convert to windows style path
winPath=$(wslpath -m $arg)
new_arg+=$winPath
} else {
new_arg+=$arg
}
}
$(sumatrapdf.exe $new_arg)
and in VimTeX set:
vim.g['vimtex_view_general_viewer'] = 'open-sumatra.sh'
the main concept is, once the string in arguments, which starts with"/mnt/" will be converted to windows style path and re-call the sumatraPDF.
So far it works with the loading pdf file, but not so robust I think, Because I’ve never written a script before...
but a new error is
unknow source: D:\xxxx\main.tex
Since the issue is not in VimTeX side, I will close for this.
Thank you all @lervag @TryerGit
Sorry for the late response, as your suggestions, I have created a zsh-script called
open-sumatra.sh
in~/.local/bin
defined as …
Yes, this looks quite good. It doesn't need to be perfect as long as it works.
So far it works with the loading pdf file, but not so robust I think, Because I’ve never written a script before... but a new error is
unknow source: D:\xxxx\main.tex
That's strange. It is unclear where this error appears. Inside SumatraPDF? If so, then I believe the best way to debug is to test various forms of the command used in the command line. For instance, in a WSL terminal, try to run these commands:
SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 'D:\Project\main.pdf'
SumatraPDF.exe -reuse-instance -forward-search 'D:\Project\main.tex' 1 'D:\Project\main.pdf'
Do you see the error in both of these?
Hi @lervag
SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 'D:\Project\main.pdf'
Will return the same error message as my script:unknow source file : (D:\xxxx\main.tex)
change to SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 'D:\Project\main.pdf'
then it will return unknow source file: (\\wsl$\Ubuntu\mnt\d\Project\main.tex)
Issue may be related: https://github.com/sumatrapdfreader/sumatrapdf/issues/377
The issue you link is related, but I'm not sure if it is exactly the same.
I believe the problem is related to the inherent conflict that you are using a Windows application as PDF reader with a document compiled with synctex in a Linux environment. The synctex file uses a syntax that includes the source file path, and SumatraPDF probably does not "understand" the unix type paths. Or something like that. You can check this by examining the .synctex.gz
file. First unzip the file, then read it with any editor. If I'm right, the synctex file will have /mnt/d/...
paths, whereas SumatraPDF uses D:\
paths. As a test, you could try to change the paths in the synctex file and gzip it again afterwards. I believe things should work then.
Hi @lervag
I have opened the main.synctex
file and search with main.tex
SyncTeX Version:1
Input:1:/mnt/d/project/ ./main.tex
...
and then replace it with
Input:1:D:\project\./main.tex
then give command line
SumatraPDF.exe -reuse-instance -forward-search 'D:\Project\main.tex' 1 'D:\Project\main.pdf`
It works !
Now the question would be, how to control the *.synctex
to overcome my problem
First, I'm glad to hear you tested this and can verify it works. It means I understood things correctly (I wasn't quite sure).
I think it would be possible to overcome the problem by making the wrapper script more advanced. It would require some semi-advanced scripting, e.g. a flow like gunzip ... -> advanced sed (or similar) -> gzip
. I don't have the time to actually suggest something concrete here, but if you do expand the script you suggested in this comment, then please feel free to share the updated version. It may be of interest to more people.
In fact, this story could potentially be a helpful addition to the faq section (e.g. "How can I use VimTeX with SumatraPDF in Vim/Neovim in Windows WSL?"), at least if you happen to find something that works well.
Hi @lervag. After some searchs I finally get it to work now. I have found a command in forum:
find -maxdepth 1 -name "*.synctex.gz" -execdir \
bash -c 'cat "{}" | gunzip | sed --expression="s@/mnt/\(.\)/@\1:/@g" | gzip > "{}.tmp" && mv "{}.tmp" "{}"' \;
Explanation:
*.synctex.gz
file under current working path*.synctex
file/mnt/
to let the /mnt/d/
like path to windows style d:/
in *.synctex
*.synctex.gz
My script is now like:
#!/bin/zsh
# This script is used to let the SumatraPDF open the pdf after path conversion
new_arg=() # ceate arguments array
declare -i idxMntOccur=0
for arg ($@) {
if [[ "$arg" == /mnt* ]] {
# convert to windows style path
idxMntOccur=idxMntOccur+1
winPath=$(wslpath -m $arg)
new_arg+=$winPath
if (($idxMntOccur == 1)) {
# convert the path in .syntex to windows style
# run only "/mnt/d" like path is detected
find ${PWD} -maxdepth 1 -name "*.synctex.gz" -execdir \
bash -c 'cat "{}" | gunzip | sed --expression="s@/mnt/\(.\)/@\1:/@g" | gzip > "{}.tmp" && mv "{}.tmp" "{}"' \;
}
} else {
new_arg+=$arg
}
}
$(sumatrapdf.exe $new_arg)
Hi @lervag. After some searchs I finally get it to work now. …
Very cool! I took the liberty of slightly cleaning up your post, and I will write a short faq entry with a link to it. If that is OK with you, that is?
In case you should adjust or improve this further, please feel free to update your comment and/or continue the thread.
Hi @lervag. After some searchs I finally get it to work now. …
Very cool! I took the liberty of slightly cleaning up your post, and I will write a short faq entry with a link to it. If that is OK with you, that is?
In case you should adjust or improve this further, please feel free to update your comment and/or continue the thread.
Of course, just take it without any restrictions. What I have done is just under your suggestions.
Description
Using Windows 10 WSL1 + NeoVim + VimTeX. LaTeX project is located in
D:\Project
SumatraPDF is the default PDF viewer in WindowsAccess the project in WSL1 via
cd /mnt/d/Project
then call nvim. After successfully compiling the sumatraPDF shows error while loading the PDF file:D:/mnt/d/Project/main.pdf
From my understanding, the path is wrong, there shouldn't be
/mnt/d
thereSteps to reproduce
D:\Project
cd /mnt/d/Project
, then enter neovim vianvim
D:/mnt/d/Project/main.pdf
Related Settings:
Expected behavior
After the compiling,sumatraPDF should be automatically called and loading the generated PDF
Actual behavior
SumtraPDF cannot load the generated PDF error, shows the error, "loading file:
D:/mnt/d/Project/main.pdf
", the path is wrong, it shouldn't contain "/mnt/d"Do you use a latexmkrc file?
No
VimtexInfo