Synctex support for wsl#5713
Conversation
`BuildOpenFileCmd` used to call `path::NormalizeTemp` unconditionally before building the inverse-search command line, and OnInverseSearch's source-file recovery fallback called `file::Exists` on the resolved source path. Both assume a Windows path and misbehave on anything else. Moved both into `DocToSource` (`Pdfsync::DocToSource` and `SyncTex::DocToSource`), the one place that already knows the resolved path's origin and format. `BuildOpenFileCmd` and `OnInverseSearch` no longer reason about path format at all; they just use whatever `DocToSource` returns. `DocToSource` is now the single place that decides how a path should be resolved, depending on its format. This is just preparation for WSL SyncTex support, no behavior change.
Adds tests/issue-5702.ts, covering forward and inverse search across two
WSL-related workflows that don't work yet:
1. files on the WSL filesystem, compiled from inside WSL
2. files on the Windows filesystem, compiled from inside WSL
(e.g. via wsl.exe -d Ubuntu -- tectonic against a /mnt/c/... path)
Uses Tectonic (run via WSL) to produce a real PDF + .synctex.gz pair for
each workflow, then drives the control-pipe TestSynctex and
TestInverseSearch commands to query SourceToDoc/DocToSource directly.
All four scenarios fail at this commit, as expected, the fixes land in
the following commits, one scenario at a time.
`SyncTex::SourceToDoc` now converts a WSL UNC source path (`\\wsl.localhost\Ubuntu\...`) to its Unix equivalent before querying SyncTeX, since the `.synctex.gz` file (compiled inside WSL) records the plain Unix path, not the UNC form Sumatra receives when the user opens the file. 1/4 scenarios in tests/issue-5702.ts now pass (forward search, WSL files).
`SyncTex::DocToSource` now detects when the sync file itself lives on WSL and, in that case, treats the recorded source path as a Unix path: resolves relative paths against the sync file's own directory instead of treating it as a Windows path, and skips Windows-specific normalization (`path::NormalizeTemp`) and the missing-source-file recovery fallback, neither of which are meaningful for a Unix path. 2/4 scenarios in tests/issue-5702.ts now pass (forward + inverse search, WSL files).
If a `.tex` file lives on a Windows drive but was compiled from inside WSL (e.g. wsl.exe -d Ubuntu -- tectonic against a /mnt/c/... path), the resulting `.synctex.gz` records Unix-style `/mnt/c/...` paths even though Sumatra receives a native Windows path when the user opens the file. `SyncTex::SourceToDoc` now retries with the path translated to its WSL mount-path equivalent if the initial query (using the Windows path as-is) fails. 3/4 scenarios in tests/issue-5702.ts now pass (forward search for both workflows, inverse search for WSL files).
`SyncTex::DocToSource` now also treats a recorded source path as Unix-style if it starts with `/mnt/`, covering the case where the PDF lives on a Windows drive but was compiled from inside WSL. As with the WSL-files case, this means resolving relative paths against the sync file's directory and skipping Windows-specific normalization and the missing-source-file recovery fallback for these paths. 4/4 scenarios in tests/issue-5702.ts now pass.
|
Codex flagged 2 issues:
|
`testForwardSearchWinFiles` and `testForwardSearchWslFiles` are merged into one generic `testForwardSearch` similarly a generic `testInverseSearch` now replaces `testInverseSearchWslFiles` and `testInverseSearchWinFiles`
…rd-slash windows paths The test will fail as our wsl synctex support patch doesn't recognize forward-slash windows paths (e.g C:/) as windows paths. The next commit will fix this issue and make the test pass.
…`WindowsPathToWslMountPathTemp`
…UnixSourcePath` The segment after /mnt/ is now required to be exactly one letter followed by '/' or end-of-string.
|
One note on merging: I have given a special care into making sure the commits are small and incremental with detailed messages explaining the reasoning behind each of them. If it's not too much trouble, I'd appreciate a rebase/fast-forward merge rather than a squash, I think the commit history might be useful on its own if anyone needs to trace back why a particular piece of WSL handling was added later. Totally understand if squashing is your preferred workflow though, just wanted to mention it. |
2 participants
Closes #5702, #5660, #1861
I've broken this PR into small, gradual commits with detailed messages,
so the history itself documents what changed and why, starting with
groundwork, then one test-passing scenario per commit. Hopefully makes this easier
to review.