Here's a script I hacked together last night.
If you're writing something with lots of complicated diagrams (like my thesis, to pick an example at random) then you often have to go through several compile-view-edit cycles before any particular diagram looks right. This involves a lot of tedious waiting. The obvious way to speed it up is to try and reduce the time between making an edit and seeing the results.
Hence this script. The idea is that you can 'watch' a LaTeX document, so that whenever you save a change the display is updated as quickly as possible to reflect the change.
The script is currently somewhat inflexible in its assumptions. It compiles .tex -> .dvi -> ps, and uses gv as the PostScript viewer. If other people are interested, I can certainly make it more configurable. That's why I'm posting it here.
The reason for the aparently-perverse choice of gv as the viewer is that ps2pdf is really, really slow, so if you want a fast cycle – and you're using PostScript specials – you need to view the DVI or PS directly. I don't know a DVI previewer that works with the PostScript specials I use, so that leaves PS. I don't know of anything else for the mac that can display PS as quickly as gv (I'd love to be enlightened here), and gv is very pleasant to use once you get used to its idiosyncratic interface.
Anyway, that means you'll need to have X11.app and gv installed for it to work. As I say, this can potentially be changed, but that's the current situation. You also need to have gv in your $PATH.
Apart from avoiding PS->PDF conversion, the main trick I use to speed up the update cycle is to build a custom TeX format file for the document. The preamble – i.e. anything before \begin{document} – is compiled into a special format when the file is watched. Thereafter, when the file is updated, the preamble is merely inspected to see whether it has changed. If it hasn't, the previously-generated format is used. Assuming you don't change the preamble very often, this is a big win if you load a lot of large packages. It halves the compile time of the document I'm currently working on.
Attached are two files:
Watch document.tmcommand A TextMate command that invokes the watcher. Copy this into your favourite bundle. (If you try to watch a file that's already being watched, you're given the option to stop watching it. Alternatively you can just close gv, and it will stop watching. Note that quitting TextMate will *not* stop the watcher.)
latex_watch.pl A Perl script that does the real work. This should be placed in the directory Support/bin inside the same bundle that you copied the command into. (You probably need to create that directory.)
If something doesn't work, you _should_ get a nice error dialog telling you what went wrong.
I'd really appreciate any feedback. I think that, with some more flexibility, something like this could be useful to a lot of people.
Robin
Robin Houston wrote:
Here's a script I hacked together last night.
Great idea!
I checked out your LaTeX watch and had problems adding gv to my PATH environment when writing "export PATH=" and so on in Terminal i can input "gv" and it tells me that it cant be run from Terminal. When writing the same command in X11's Terminal i can't start gv from the Terminal :-o What's wrong there?
I searched through Google about 4 hours when i saw your LaTeX watch here on the mailing list and found nothing interesting regarding PATH environment.
Thanks
Excellent, I'm pleased that someone is interested! About your problem:
1. What error message do you get, when you try and run gv from the Terminal? 2. Have you actually installed gv? If so, where is it installed?
I'll attach the current version of LaTeX Watch, which has better error handling.
Robin
Robin Houston wrote:
Excellent, I'm pleased that someone is interested! About your problem:
- What error message do you get, when you try and run gv from the
Terminal? 2. Have you actually installed gv? If so, where is it installed?
I'll attach the current version of LaTeX Watch, which has better error handling.
Robin
I was very confused that nobody else is interested in this thing. I thought, lets wait a while this will be a thing everybody wants to have. But nothing happened :-/
2. gv is inside /sw/bin/ 1. I found the error...i can now start gv from terminal but i have to enter export before. I had the false syntax for export now i can run it from within X11's Terminal.
But when i try to watch the document nothing happens.
Zettt
Robin Houston wrote:
Excellent, I'm pleased that someone is interested! About your problem:
- What error message do you get, when you try and run gv from the
Terminal? 2. Have you actually installed gv? If so, where is it installed?
I'll attach the current version of LaTeX Watch, which has better error handling.
Robin
I was very confused that nobody else is interested in this thing. I thought, lets wait a while this will be a thing everybody wants to have. But nothing happened :-/
2. gv is inside /sw/bin/ 1. I found the error...i can now start gv from terminal but i have to enter export before. I had the false syntax for export now i can run it from within X11's Terminal.
But when i try to watch the document nothing happens.
Zettt
Okay, I guess a lot of people might want to use Fink to install gv, so I've added /sw/bin to the path in the script. However, if that were the only problem, you ought to get an error dialog from my script. I guess the reason nothing happened at all is that you didn't set the executable bit on the script.
I attach a new version (1.2) which ought to solve these problems. If it still doesn't work, then go into the Bundle Editor, click on the watch command, and change "Output: Discard" to "Output: Create New Document". Then try it again — you should then get a document containing relevant error messages.
Thanks for testing!
Robin
Robin Houston wrote:
I guess the reason nothing happened at all is that you didn't set the executable bit on the script.
The new Document is empty.
I am very interested in LaTeX Watch. Some people never experience slowdowns, especially with their Intel machines, but I have longed for something like this when formatting large documents.
Jenny
On Apr 2, 2007, at 6:09 AM, Robin Houston wrote:
Okay, I guess a lot of people might want to use Fink to install gv, so I've added /sw/bin to the path in the script. However, if that were the only problem, you ought to get an error dialog from my script. I guess the reason nothing happened at all is that you didn't set the executable bit on the script.
I attach a new version (1.2) which ought to solve these problems. If it still doesn't work, then go into the Bundle Editor, click on the watch command, and change "Output: Discard" to "Output: Create New Document". Then try it again — you should then get a document containing relevant error messages.
Thanks for testing!
Robin
<Watch document.tmcommand> <latex_watch.pl>
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 4/2/07, Jenny Harrison harrison@math.berkeley.edu wrote:
I am very interested in LaTeX Watch. Some people never experience slowdowns, especially with their Intel machines, but I have longed for something like this when formatting large documents.
It does make a big difference, especially if you need to compile via PostScript (e.g. if you're using PSTricks). For the document I'm working on at today, it takes more than a minute to generate a PDF file from the source, but only 5 seconds to update the preview using this script.
Even for documents that don't need PostScript specials, it's still several times faster on my machine.
Please do give it a try, when you have the time, and let me know whether it works (or if not, why not).
Thanks, Robin
On 2. Apr 2007, at 15:09, Robin Houston wrote:
I attach a new version (1.2) which ought to solve these problems. If it still doesn't work, then go into the Bundle Editor, click on the watch command, and change "Output: Discard" to "Output: Create New Document". Then try it again — you should then get a document containing relevant error messages.
FYI you can reopen stdout/err as /dev/console, that way, output goes to the system console, and users can just look there for potential errors.
On 4/2/07, Allan Odgaard throw-away-1@macromates.com wrote:
FYI you can reopen stdout/err as /dev/console, that way, output goes to the system console, and users can just look there for potential errors.
That's a useful tip, thanks!
Robin
On 4/2/07, Zettt zettt@macbay.de wrote:
I was very confused that nobody else is interested in this thing. I thought, lets wait a while this will be a thing everybody wants to have. But nothing happened :-/
Well, it looks like you reinvented latexmk. http://www.phys.psu.edu/~collins/software/latexmk-jcc/
Using latexmk, this is the command I use to start a process that will typeset automaticaly whenever you save the current file:
M=${TM_LATEX_MASTER:-$TM_FILEPATH} DIR=`dirname "$M"` FILE=`basename "$M"` open -a Terminal osascript <<-APPLESCRIPT tell application "Terminal" do script "cd "$DIR"; latexmk -pvc -pdf -quiet "$FILE" " end tell APPLESCRIPT
On 4/3/07, Martin Bialasinski klingeling@gmail.com wrote:
open -a Terminal osascript <<-APPLESCRIPT tell application "Terminal" do script "cd "$DIR"; latexmk -pvc -pdf -quiet "$FILE" " end tell APPLESCRIPT
That seems unnecessarily roundabout. You could avoid Terminal altogether by doing:
bash <<BASH &>/dev/null & cd "$DIR" latexmk -pvc -pdf -quiet "$FILE" BASH
If you try Latex Watch, you should find it noticeably faster than latexmk, which might be a clue that it's not just doing the same thing. :-)
Robin
On 29. Mar 2007, at 11:43, Robin Houston wrote:
[...] I'd really appreciate any feedback. I think that, with some more flexibility, something like this could be useful to a lot of people.
I agree, this should definitely be a candidate for the LaTeX bundle, *but* we need it working with pdflatex ;) I think that is what 99% of people (on a Mac) use.
On Apr 2, 2007, at 12:57 PM, Allan Odgaard wrote:
On 29. Mar 2007, at 11:43, Robin Houston wrote:
[...] I'd really appreciate any feedback. I think that, with some more flexibility, something like this could be useful to a lot of people.
I agree, this should definitely be a candidate for the LaTeX bundle, *but* we need it working with pdflatex ;) I think that is what 99% of people (on a Mac) use.
Yes this would be great to see added to the bundle, but we need to modularize it a bit first, so that we can make it work with pdflatex as well, when ps output is not required. Also, we need to somehow make it so that the watcher stops watching a file that is not open in TM anymore. Not sure how to achieve that last one though.
And ideally rewrite it in ruby, so that we can use the dialog.rb library instead of all these direct CocoaDialog calls (and so that I can actually read it ;) ).
Actually, it's really a question of just speeding up the compile, right? Is there really much speed gained in having the recompile done automatically instead of triggering it via cmd-R? In other words, is the overall speedup mostly in using the ini stuff?
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 4/2/07, Charilaos Skiadas skiadas@hanover.edu wrote:
Yes this would be great to see added to the bundle,
That's encouraging!
but we need to
modularize it a bit first, so that we can make it work with pdflatex as well, when ps output is not required.
Sure. I don't know what would be most suitable as a previewer for this – probably Texniscope?
Also, we need to somehow
make it so that the watcher stops watching a file that is not open in TM anymore. Not sure how to achieve that last one though.
I'm not sure either. Note that it does stop watching when you close the previewer.
And ideally rewrite it in ruby, so that we can use the dialog.rb
library instead of all these direct CocoaDialog calls (and so that I can actually read it ;) ).
I have no objection to that, and I know some Ruby, but I'm not fluent in it the way that I am in Perl.
Actually, it's really a question of just speeding up the compile,
right?
That was my main concern, but I also find it useful to have it updating quietly in the background whenever you save, rather than having to explicitly open it afresh every time. That way you can see the effect of your changes very easily. I don't use Texniscope, because it doesn't work with PS specials, but I assume that it offers some of the same convenience, e.g. staying on the same page when the file is recompiled?
Is there really much speed gained in having the recompile done
automatically instead of triggering it via cmd-R? In other words, is the overall speedup mostly in using the ini stuff?
For my documents, the overall speedup is overwhelmingly in not generating PDF from PostScript, which is insanely slow. But after that, the format caching also roughly halves the time needed (again for my documents, on my computer. Your mileage may vary).
Apart from convenience, the other reason for having a long-running process monitoring the file, rather than spawning a new one for every refresh, is that data can be cached in memory. Currently this is done for the text of the preamble, so the script can tell when it has changed.
Robin
-
Allan Odgaard -
Charilaos Skiadas -
Jenny Harrison -
Martin Bialasinski -
Robin Houston -
Zettt