Inconsistent pdf->source sync with symlink folder

[lucmos]

I have as workspace a symlink folder.
When I do ctrl + click to go from the pdf to the source, the file that is opened is the one with the real path.

e.g.

The problems:

• If I modify this automatically opened file, the build process does not work. I have to close both, re-open the symlinked one and then it works.
• There are some problems on how code handles this situation, when the same file is opened from multiple paths: Issues with not case/fragment-normalizing file paths (macOS, Windows) microsoft/vscode#12448

The problem seems to appear even if I open the real folder in the workspace. Maybe the problem is that it is on a mount point?
On the notebook, where the folder is in ~/Documents I do not have this problem

[jlelong]

The problem is that synctex fully resolves symlinks during compilation and writes the resolved path in the .synctex.gz file. Not clear to me how we can handle the problem from the extension side. Don't we have to wait until vscode handles symlink properly?

Yet, I am a bit confused by

The problem seems to appear even if I open the real folder in the workspace. Maybe the problem is that it is on a mount point?

[tamuratak]

I will look into this issue. Since any fix will conflict with my PR, #1030, please wait until the PR is merged.

[jlelong]

I just want to share my thoughts about this problem.

• vscode's API does not give access to the list of opened editors: see the feature request.
• In the extension, we keep track the tex file tree in Manager.texFileTree.
• Before firing up a new editor from synctex, we could check whether a file from Manager.texFileTree resolves to the result of synctex.

Hope this will help.

[lucmos]

Yet, I am a bit confused by

The problem seems to appear even if I open the real folder in the workspace. Maybe the problem is that it is on a mount point?

I'm confused too, since I don't seem to be able to reproduce the problem with a new, clean workspace. As I have time I'll try to do more tests

[jlelong]

@tamuratak I have just fixed this for Kpathsea/synctex but I am not sure what to do for synctexjs. Can you have a look.

[tamuratak]

I can't reproduce this issue even without 8b5d00b.

Mac OS X: 10.13.6
VS Code: 1.30.1
LaTeX Workshop Version: 5.19.0

[jlelong]

I have managed to reproduce the issue with the following directory structure

top
  |-- dir1
  |      |-- main.tex
  |      |-- subfile.tex (called by main.tex via \include)
  |-- link-to-dir1

Run code -n link-to-dir1 and open main.tex. Then, compile and view. Call synctex from the PDF file at a position resolving to subfile.tex, it will open top/dir1/subfile.tex instead fo link-to-dir1/subfile.tex.

Not so easy to reproduce but it can be annoying. I hope 8b5d00b fixes this properly.

[tamuratak]

Thank you, I can reproduce this issue now. I also confirm that 8b5d00b solves it.

[lucmos]

So do I, I'm not experiencing the problem anymore!