Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

The forward search script I had written for vim and mupdf is no longer working since installing TL 2011, and upon investigating why, it seems that synctex is now very fussy about filenames, at least for synctex view. Not only does it require the full path, but it requires a redundant /./ at the end of the path.

To duplicate. Let scratch.tex be:

 \documentclass{article}
 \begin{document}
 Hello world
 \end{document}

Now, look at the results of the following from the command line:

kck@kck-desktop ~/tmp $ pdflatex -synctex=1 scratch.tex &>/dev/null
kck@kck-desktop ~/tmp $ synctex view -i 3:1:scratch.tex -o scratch.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX Warning: No tag for scratch.tex
kck@kck-desktop ~/tmp $ synctex view -i 3:1:/home/kck/tmp/scratch.tex -o scratch.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX Warning: No tag for /home/kck/tmp/scratch.tex
kck@kck-desktop ~/tmp $ synctex view -i 3:1:/home/kck/tmp/./scratch.tex -o scratch.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX result begin
Output:scratch.pdf
Page:1
x:171.128296
y:134.764618
h:133.768356
v:134.764618
W:343.711060
H:6.918498
before:
offset:0
middle:
after:
SyncTeX result end

Using this syntax for synctex is very counterintuitive, and I'm hesitant to fix my script to use these kinds of filenames for fear synctex's syntax will again be changed.

This problem did not exist for me in TeXlive 2010. Is this change intentional, and will it last?

share|improve this question
add comment

3 Answers

The switch from relative paths to absolute paths is intentional and will stay, as that is a requirement for the --output-directory switch to work.

The fuzzyness with embedded /./ can probably be fixed, but that should be taken up with Jérôme Laurens (the synctex developer). The easiest way to reach him is to send an email message to the TeX Live mailing list. See Tug's texlive homepage for more information.

share|improve this answer
1  
Yeah, but putting /./ in there is seriously weak sauce, and it breaks apps tightly coupled to distributions that actually embed the synctex library and it's not really easy to swap those out. WTF? –  towolf Oct 25 '11 at 16:32
add comment

I know that this question is rather old, but I thought I'd add my solution since this result came up while I was searching for the cause of the problem.

Background

It appears that what happens is that path names stored within the .synctex.gz file are determined by the kpathsea library. For example, I include each chapter of my thesis from a different file, so my background information is written in the file background.tex. Before the fix, the path name to that file is stored as /home/user/thesis/./background.tex, which is due to the fact that the working directory was /home/user/thesis and the relative path to background.tex according to kpsewhich was

$ kpsewhich background.tex
./background.tex

Putting the paths together, it is easy to see why the synctex file stores /home/user/thesis/./background.tex as the file name. This also suggests the solution though...

Solution

The solution is to have kpathsea output a correctly formatted path, and that is accomplished by having kpsewhich not return any relative paths. This is accomplished by setting an environment variable (TEXINPUTS) telling the kpathsea library that the current directory is actually part of the library path. (Note that the trailing colon is necessary. Without it, the default TeXLive paths are forgotten and any standard packages cannot be found. The colon tells kpathsea to also append the default list to the paths given in the environment variable.)

$ TEXINPUTS="$PWD:" xelatex -synctex=1 thesis
....
$ synctex view -i 3:1:/home/user/thesis/background.tex -o thesis.pdf
This is SyncTeX command line utility, version 1.2
SyncTeX result begin
Output:thesis.pdf
Page:11
x:128.365967
y:312.158264
h:108.000008
v:315.374176
W:413.999969
H:11.763868
before:
offset:0
middle:
after:
SyncTeX result end

My favorite way of executing this is to setup latexmk to automatically set the environment variable whenever it is executed. I already used latexmk to simplify the multiple passes required by LaTeX anyway, so why not have it also work around the SyncTeX bug for us as well ;-P. This can be done by either editing your global (~/.latexmkrc) or local ($PWD/.latexmkrc) configuration files. Just add the line

$ENV{TEXINPUTS} = "$ENV{PWD}:";

to the file and you'll find that SyncTeX will actually work as expected now (e.g. between gedit and Evince).

share|improve this answer
    
Using TEXINPUTS and PWD does interesting stuff with symbolic links: in the context of my answer below, the environment variable PWD doesn't resolve symlinks, so the symlinked-path appears in the synctex.gz file, if you used the symlink name when changing directories. On the command line, I would recommend "TEXINPUTS="$(pwd -P):" pdflatex ..." to get the absolute path, and in your .latexmkrc file, use $ENV{TEXINPUTS} = getcwd() . ":"; –  Dan Drake Apr 4 '12 at 11:34
    
@DanDrake, Thanks for the fix. I came up with this solution while trying to fix my thesis build, and since it doesn't make use of any symlinks, I never considered whether there'd be a problem with them or not. I'm sure I'll hit this situation at some point in the future, though, so it's good to know there is a way around it. I've updated my .latexmkrc accordingly. –  jmert Apr 4 '12 at 15:28
add comment

Another problem with this fussiness is symlinked directories. If I have my document in

/home/user/long-dir-name

and a symlink /home/user/foo -> /home/user/long-dir-name, then if my editor uses ~/foo/doc.tex, SyncTeX will be confused since it used ~/long-dir-name/doc.tex.

This requires getting your editor to munge the filename just like kpathsea did, since SyncTeX can't figure out what your editor will think. In Emacs, using (file-truename buffer-file-name) in your elisp seems to work well, along with the above environment variable trick.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.