In three words: it doesn’t work (does “doesn’t” count as 1 or 2 words though?).
A bit more detail. After a long hiatus, I fired up a Parallels 7 virtual machine and decided to use SumatraPDF and Sublime Text 2 under Win7 for my day’s work (which is, as usual, LaTeX-heavy). However, synchronization (i.e. jumping from the LaTeX source to the PDF output and conversely) kept failing with the particular file I was working on . This was both surprising and worrisome: I have been developing the LaTeXTools plugin for ST2 under Mac OSX lately, but my focus has been on cross-platform features; I assumed that the sync infrastructure, which is very platform-specific, was in a stable state by now. Still, one can never rule out new bugs with updates to both ST2 and SumatraPDF; this is the reason why I occasionally take a trip to the Win7 side, as I did today.
Ends up the problem is not with ST2 or with the LaTeXTools plugin: the sync infrastructure is still solid on Win7. Rather, the failure of synchronization is a well-known issue that affects the (otherwise excellent) MikTeX distribution. Like many other TeX distros, MikTeX relies on a library called “synctex” to generate the synchronization information (the “.synctex.gz” files that get created whenever you pass the “-synctex=1” option to pdflatex). Unfortunately, if the LaTeX source file name (more precisely, its full path name) contains a space, the generated sync information is incorrect.
I double-checked this two ways: first, if there are no spaces in the path name, ST2+SumatraPDF work just fine; second, if there is a space in the file name, then synchronization also fails in TeXworks. Google says it fails with WinEdt, TeXmaker and other editors as well. Incidentally, the TeXworks test exonerates SumatraPDF, because TeXworks and SumatraPDF use different libraries to render PDF files (although they both use synctex for backward and forward searches).
Now, in principle, the problem may be with the synctex library itself. However, on Mac OSX, synchronization works fine with file names that include spaces. The synctex code is largely cross-platform, so the problem must be in the way MikTeX incorporates or adapts it on Windows. One way to test this would be to run the TeXlive distribution on Windows; it, too, includes synctex, and the standard Mac TeX distribution, aptly named MacTeX, is essentially just TeXlive compiled under OSX, with some additional apps. Since MacTeX generates correct sync info with or without spaces in file names, I suspect that TeXlive under Windows does, too. If anyone has experience with this, please let me know in the Comments.
Bottom line: this is a Windows- and MikTeX-specific, back-end problem that unfortunately I cannot fix. I hope a future release of MikTeX will resolve the issue, because I do occasionally use spaces in file names. In the meantime, the fix is to, well, stick to file and directory names that have no spaces in them.