LaTeXTools not running viewer in Windows 10

[D-Pow]

Issue

viewer is never executed regardless of settings, resulting in PDF file never opening

Settings

I currently set view_command as simple as possible: directly opening the file with default Windows program for .pdf files.

"builder": "",
"viewer": "command",
"viewer_settings": {
    "osx" : {
    },
    "windows" : {
        "view_command": "start /B \"\" \"$pdf_file\""
    },
    "linux" : {
    }
},
"open_pdf_on_build": true,

System

• Sublime Text 3 Build 3143
• Windows 10
• Latest version of LaTexTools

[ig0774]

IIRC start isn't properly a separate Windows executable but a shell built-in (i.e., it only works in the context of a command prompt). So to get this to work, you need to actually invoke cmd.exe something like (untested and all the escape sequences get confusing):

"cmd /k \"start /B \"\"$pdf_file\"\"\""

It might work as:

"cmd /k start /B \"$pdf_file\""

[D-Pow]

Thanks for the reply, I could play around with the syntax there and see what I can get.

In the meantime, your comment brings up a more important question (where mine is more of a "give a man a fish" but yours is "teach a man to fish"): How exactly is the value for the view_command key used? Is it passed to a bundled bash/shell, run directly on the OS' native terminal, or otherwise? I feel like the fact that I'd have to add view_command: "cmd /k my-command" means that the command is not being run natively but through some other process.

[ig0774]

The command you pass in to the command viewer is passed to a Python subprocess.Popen() call, which allows us to directly ask the OS to run an executable, so the shell doesn’t really enter into the equation. You can do (very roughly) the same thing in the Windows Run Command utility (WinKey + R). The reason that we use the OS directly is that it avoids creating a new shell instance just to run a single command (which is relatively expensive if you don’t need it).

(If you really want the gory details: Popen on Windows calls the CreateProcessW C function to create a new process using a specified executable; that’s why the first part of the command needs to be an executable the OS can find directly; our use of Popen can be found in the source code here which invoked by the command_viewer source here).

Sorry for not having a ready-to-go answer; I don’t use Windows very much these days.

[D-Pow]

Honestly, that second "gory details" section is super helpful. No need to apologize, now that I understand what's going on under the hood, I can diagnose/troubleshoot myself. Again, teaching me to fish rather than just giving me the fish.

Going forward with this ticket, I'm happy to have this issue closed since it was based on a misunderstanding of how LaTeXTools works. However, I think it would be a good idea to make this explicit in the website docs so others don't open new issues/take up developers' time with questions like this. I'm not exactly sure what wording should be used that would cater to the largest audience, though.

Alternatively and even better, maybe this ticket could be converted to a feature request to add an option for opening the compiled file with the OS' default program (that's the only reason I'm trying to use cmd /k start "pdf_file"). The claim that e.g. "SumatraPDF is the default PDF viewer on Windows" is simply not true; usually, Windows defaults opening PDFs with a browser or a particular program if one were installed (e.g. Adobe). And if LaTeXTools could support an "os_default" option in the viewer_command, that would be absolutely perfect.

[ig0774]

There’s definitely some stuff in the docs we should clarify and we’d always welcome suggestions on that front. When the docs say “SumatraPDF is the default viewer...” it really means that we assume if you’re using Windows, you want to use SumatraPDF. This is because it has support for SyncTeX (forward and inverse jumping between editor and viewer) and is generally useful for editing LaTeX documents (Adobe’s reader opens the PDF in a mode that causes Windows to lock the file; this is fine for viewing a PDF, but when editing a PDF it means you have to close the Adobe window before building the document or else the changes won’t get written to the PDF file; this is also a factor in why we never created an “os_default” viewer—it might be worth reconsidering that though).

To clarify a bit more: Sumatra is the default viewer on Windows the same way Skim is the default viewer on Macs. Macs also have Preview which can view PDFs, but which cannot support forward and inverse search. Similarly, our “default” on Linux is Evince, even though that’s a Gnome-specific app and KDE users will presumably want to use Okular.

[D-Pow]

Re docs: Yeah, my other issue #1500 was another one dedicated solely to a documentation bug I discovered.

Re default viewer: I should be careful when I say "simply not true" and/or "SumatraPDF is [not] the default viewer" as this is dependent on a person's individual setup. At the very least, I agree with you that Adobe is super annoying when it comes to repetitive LaTeX builds for the exact reason you mention (the lock on the file). Still, I think it would be a worthwhile venture to pursue the "os_default" since that gives a fairly simplistic option for people that don't use LaTeX often and want to have a plug-and-play experience (like me).

As before, you're going into a level of depth that I appreciate and I feel like this is a productive conversation. Thanks for the feedback and explanations :)