Tag Archives: texlive

LaTeXTools plugin: a slew of fixes

I finally got around to committing a bunch of fixes for my LaTeX plugin for the Sublime Text 2 editor. I describe the main changes below. First though I really want to give a shout-out to the outstanding Package Control plugin, which makes it trivially easy to install and update LaTeXTools and most other Sublime Text 2 plugins. If you have Package Control installed, getting LaTeXTools on your Mac or PC is just a matter of invoking Package Control: Install Package via either the Command Palette or the Preferences menu. See the aforelinked page for details. Incidentally, I didn’t have to do anything to make sure LaTeXTools was picked up by Package Control: it happened automagically, to my surprise and delight. Yay!

Now for the fixes. In no particular order:

  • I expanded the README file so it now covers most, if not all, of the current functionality. I also provide some ideas on how to troubleshoot issues. By the way, if you do find something is wrong, please let me know!
  • I finally understood that latexmk does not automatically force the TeX engine (e.g. pdflatex) to work in batch mode. Errors will cause latexmk to stop. You can check this by running it from the command line. However, on OS X, somehow invoking latexmk via subprocess.Popen still works, in the sense that all processes terminate regularly and the plugin can then look for errors in the TeX log file. On the other hand, on Windows, using TeXlive, this is not the case: the build command essentially hangs, and even if you terminate it, the pdflatex process keeps waiting for input in the background. This makes further compilations fail (because the synctex file is locked), and forces you to terminate the stray process with Task Manager. Ugly! Well, I hope I have fixed at least the most egregious causes of such inappropriate behavior by passing the -silent option to latexmk.
  • A user had a lot of trouble with on-the-fly conversion of EPS files to PDF on OS X, using the epstopdf package. Ends up the problem was path-related: epstopdf relies on Ghostscript, and MacTeX puts Ghostscript in /usr/local/bin rather than /usr/texbin. When compiling from the command line, everything worked–because MacTeX also helpfully fixes your $PATH; but, building from Sublime Text 2 always failed. Adding the former path in LaTeX.sublime-build fixed the issue. Thanks Jon and Sublimator for helping me track down this bug!
  • SumatraPDF, the supported PDF reader on Windows, only reloads recently changed files if they are local: it does not automatically reload files on network shares when they change. As a result, recompiling a file on a network share resulted in SumatraPDF not automatically showing the updated text. This was a problem for me when running Windows in a Parallels virtual machine: Mac directories are accessible are network drives, and there is no problem editing files with Sublime Text 2 on the virtual Windows side; however, I had to manually reload PDF files every time. Bottom line: I now explicitly force a reload before issuing the forward search DDE command.

Enjoy, and as usual report back any issues you may have!

TeXlive is a go (plus, a better README)

Last night I pushed the changes I made to the LaTeX.sublime-build to GitHub. You may say that TeXlive is now “officially supported” on Windows, in addition to MikTeX. As I noted earlier, I fully expected Sublime Text 2 to eventually fix its handling of non-normalized file paths and different drive letter cases. As usual, Jon has come through: as of version 2120, everything works just fine!

Also, I finally got around to beefing up the README file for the plugin. It’s in Markdown format, so it’s human-readable, but you can see it in all its HTML-formatted glory if you just go to the LaTeXTools page at Github and scroll down. I hope this will encourage more people to give Sublime Text 2 and LaTeXTools a whirl.

One final note on the choice of TeXlive vs. MikTeX. As I see it, the trade-off is this: MikTeX’s management tools, and its DVI previewer Yap, are Windows-native, whereas TeXlive’s management tools feel like ports of Unix tools, which they are (even the GUI ones). On the other hand, TeXlive has full support for spaces in file names and paths, which MikTeX currently lacks. As a further advantage, TeXlive has a working version of latexmk, which means that it is very easy to change the tex engine from pdflatex to, say, xelatex: just change the appropriate line in LaTeX.sublime-build. Finally, TeXlive on Windows is essentially the same as, and package-wise in sync with, MacTeX on OSX, which may be convenient if you’re a platform hopper like me.

TeXlive on Windows: forward and inverse search

Yesterday’s post ended with a conjecture: TeXlive should be able to generate correct sync info on Windows. Today I decided to test that conjecture; I installed TeXlive 2011, which turned out to be surprisingly simple, with one caveat: the MiKTeX installer adds its binary directory to the system path, and if you run the TeXlive installer in user mode you obviously can’t change that. To fix this, you need to add the TeXlive binary path manually, before the MikTeX path. However, if you plan on using Sublime Text 2, you don’t even need to do that, and you can use both distros  side-by-side: read on.

Supporting TeXlive/Windows in the LaTeXTools plugin turns out to be trivial. You only need to modify the LaTeX.sublime-build file! Chalk that up to Sublime Text 2′s build system design, which my plugin’s makePDF command takes advantage of.

I’ll push the changes (commented out, so the default is still MikTeX) soon; for the time being, if you want to experiment, with TeXLive, modify the “windows” section of the file LaTeX.sublime-build so that the “cmd” option looks exactly the same as it does in the “osx” (i.e. Mac) section. This is not surprising: after all, the underlying TeXlive distro is the same. Furthermore, you can use the “path” option to specify the TeXlive binary directory, so you don’t even have to mess with environment variables (make sure to add “;$PATH” after the TeXlive path).

The result is that Sublime Text 2 now works happily with TeXlive! So, does synchronization (forward and inverse search) work, even with file names that have spaces? Yes! Well, I should be precise.

First, the .synctex.gz file is correctly generated. Recall that MikTeX 2009 does not generate it if the file name contains spaces, so this is an improvement.

Second, forward search works beautifully [an aside: Ctrl-Shift-J is now bound to a folding operation, so I need to change the keyboard shortcut. Use Ctrl-B for the time being: if no compilation is required, the net effect is the same, i.e. you jump to the right position in the PDF file. Again, I'll push a fix soon].

Third, backward search (from the PDF to the tex file) sort of works. The problem is that the most recent version of synctex “extends” file paths so that

C:\Users\YourName\Documents\test.tex

becomes

C:\Users\YourName\Documents\.\test.tex

(the same is true on the Mac, btw). Clearly, both paths point to the same file. However, when you double-click in the PDF file, SumatraPDF invokes Sublime Text 2 (or whatever editor you designate) with the second, longer version of the the file name. Now, most likely, you already have the file test.tex open in a tab in Sublime Text 2; however, if you opened that file yourself (e.g. from an Explorer window, or from the Open dialog), the path name associated with the file is the first, “normal-looking” one. As a result, Sublime Text 2 opens a second tab, with the same actual file, but a different path name (the “extended” one). You can check for yourself by hovering on the two tabs: the path names are indeed different, as described above. On the positive side though, the cursor is positioned correctly, corresponding to the point in the PDF file where you double-clicked in SumatraPDF.

Now, this is not a Sublime Text problem: the exact same behavior results if you use TeXnicCenter. Furthermore, no such problem exists with Sublime Text 2 on the Mac (with the Skim previewer). Finally, neither Sublime Text 2 nor the underlying Mac OS do anything special to make sure that files of the form

/Users/YourName/Documents/test.tex

and

/Users/YourName/Documents/./test.tex

are treated as one and the same: you can try this for yourself by opening a file using the two above specifications of the file name from the Terminal.

Bottom line: it is SumatraPDF’s fault. Or, more precisely: on the Mac, the Skim app is smart enough to send a “normal” file name to your text editor when you perform an inverse search. SumatraPDF is not as smart.

Presumably, the problem does not arise if you use MikTeX because it uses a version of synctex that does not use “extended” path names—but that version, unfortunately, does not handle spaces in file names either!

The bottom line is that it’s a bit of a catch-22: either you use MikTeX, but avoid spaces in file names; or, you use TeXlive, but are forced to open files in Sublime Text 2 by using their “extended” pathname. This is easy to do: open your tex file normally, then build it, then double-click in SumatraPDF; when the second tab pops up in Sublime Text 2, close the first, and from then on work in the new  tab. Of course, you can also open the PDF file first, then double-click, and work in the tab that Sublime Text 2 opens for you. Ugly, but functional.

I will report the issue on the SumatraPDF bug tracker. Hopefully it will get fixed in a later version.