Place .sum.synctex files in temporary folder

[fefrei]

Current versions of SumatraPDF seem to uncompress SyncTeX files to the document directory when needed.

Here's the relevant code: https://github.com/sumatrapdfreader/sumatrapdf/blob/a6d299204e873e73e4185605906c376d5d06fd55/src/PdfSync.cpp#L510

I see this behavior in practice with v3.5.2, and it is a bit annoying, especially when tracking a LᴬTₑX source in Git and .synctex.gz is ignored, but .sum.synctex is not. I could change this, of course, but there's more than one repository…

I totally understand if SumatraPDF needs to uncompress the SyncTeX file and put it somewhere, but maybe a temporary folder would be a more appropriate location?

[GitHubRulesOK]

The first rule of LaTeX is as a cross platform system written in previous centuries ALL work files live in the work folder. SumatraPDF has to work with that dependency. You will see the comment "// the path to the .synctex file (even if a .synctex.gz file is used instead)" thus the working pdfsync/synctex MUST be alongside the PDF same as all other auxillary files should also be in the one project folder (no unknown subfolders or %tmp% s).

Files should be relatives in the one location. It is the job of the LaTeX Author to move the finished article from the work folder to the client, without the work folder backups / auxiliary components. Many LaTeX IDEs have a clean-up cycle on demand to delete work files at end of compilation.

[fefrei]

I understand the comment you are referencing a bit differently (saying that even SyncTex() must be passed a path to a .synctex file even if there only is a .synctex.gz), but if it's true that SyncTeX files must live alongside the PDF for reasons outside of SumatraPDF's control, so be it 😞

If it is possible to place it elsewhere, I disagree with the notion that alongside to the PDF is a good place to put it. SumatraPDF is a PDF viewer, it shouldn't be writing files to the document directory; and it disturbs users of version control. The fact many IDEs have ways of cleaning up auxiliary files is not really relevant, there's little reason to clean aux files before committing, and besides, I'm not sure many of these cleanup routines will delete a <filename>.synctex.gz.sum.synctex file – I can tell you that Latexmk does not, by default.

[GitHubRulesOK]

I agree that SumatraPDF is doing it oddly so that <filename>.synctex.gz.sum.synctex should be simply <filename>.synctex , same as any compiler run will write it for simplicity of deletion, i.e with / without .gz compression, based on compression flag (synctex= -16 to +16 ?) but the whole system was developed on Mac platform, then expanded to TL on Nix and finally Windows. Where in hindsight syncteX could nowadays have indicated a simpler zip folder content like docX or xlsX

[kjk]

There's a bug when synctex fails to parse .gz version of the file which I wasn't able to figure out and fix. Mostly because I don't use latex myself and don't have a setup for testing this.

This is a hack to make it work.

Since I don't have a setup for testing this code, I don't want to make any changes because if I break things, I won't know.

If you want to try a better fix, I'll review the PR but I'm not planning on working on this myself.

[GitHubRulesOK]

@kjk untested but if the file is unpacked insitu without .gz extension it should work as per an uncompressed sidcar file and if the default was to read the uncompressed in preference to compressed, that would be then only be an issue about enforcing overwrite, but there should not be 2 at same time anyway, thus the workaround will allow for IDE cleaning of sidcar files (unless it only expects one not 2)