Inverse search command-line messes up from time to time

[honekamp]

I'm running the pre-release version 3.2.11133. I heavily use the inverse search for LaTeX document creation. I use Visual Studio Code as my preferred LaTeX editor. Code is installed as a user-space installation (as opposed to an installation somewhere in "c:\Program Files").

The command-line for inverse search looks like

"C:\Users\username\AppData\Local\Programs\Microsoft VS Code\Code.exe" -g "%f":"%l"

However, once in a while, inverse search stops working and complains about an invalid command line. Turns out that the command line stored in Sumatra's options - without me being involved in this change - has been altered to point to "C:\Program Files\Microsoft VS Code\Code.exe" rather than to my user-based install. Hence, Sumatra tries to access Visual Studio Code at a location where no installation of it can be found.

In such cases I need to open Sumatra's Options dialog and manually correct the command-line setting before inverse search starts to work again properly.

[GitHubRulesOK]

I have used most Latex editors over a period of time for testing alternate reverse searching. I have not used vscode however all others only changed the inverse search when its included in the call.

It is highly recommended not to call repeatedly, that is, the reverse should be stored in SumatraPDF-settings.txt once and not on each invocation i.e. do not use the depreciated -inverse-search command .

There is never [this is wrong see next comment] a reason for SumatraPDF to modify the line itself (unless requested by the -inverse-search command line)

[GitHubRulesOK]

To correct my comment about SumatraPDF not modifying -inverse-search parameter there are cases where it will change the settings but luckily none should include vscode\code.exe

The failback is "notepad %f" unless SumatraPDF attempts to interfere with

"WinEdt.exe", [Open(|%f|);SelPar(%l,8)] "notepad++.exe", -n%l "%f" "sublime_text.exe", "%f:%l" "TEXCNTR.exe", /ddecmd "[goto('%f', '%l')]" "WinShell.exe", -c "%f" -l %l "gvim.exe", "%f" +%l "gvim.exe", -c ":RemoteOpen +%l %f" "texmaker.exe", "%f" -line %l "TeXworks.exe", -p=%l "%f"

It is possible since many editors share identical parameters that one TeX detection could incorrectly point to the wrong editor (I personally think the above list is best not parsed automatically per run !)