## Sunday, July 22, 2007

### SEEing LaTeX 8: Dealing with Auxiliary Files

As noted in part 5 of this series, there were three main features to add to the LaTeX mode for SubEthaEdit (SEE). I've already taken care of the first, typesetting, by taking advantage of latexmk. In this installment, I'll address the second, cleaning up the mess of auxiliary files.

LaTeX produces several sorts of auxiliary file to handle cross-references, tables of contents, bibliographies, and more. The auxiliary files are essential to how LaTeX works, but of little use when, e.g., sending a paper to a co-author or submitting it to a journal. With a bit of bad luck, it is also possible to have a corrupted auxiliary file that prevents you from creating a PDF from correct LaTeX sources; deleting some or all of the auxiliary files solves this problem.

Auxiliary file deletion is thus an infrequent, but necessary task. It would be possible to just ignore the issue and do the needed clean-up in either the Terminal or the Finder, but doing it by hand can be error prone. Also, it is simple to add to SEE. Overall, it seems worth doing.

In an earlier post, I used latexmk to trigger typesetting from SEE. With the right command line options, latexmk can also be used to clean up the auxiliary files! Adding a clean-up feature to SEE then just requires some relatively minor modifications to the scripts used for typesetting.

First, let's look at the shell script. It becomes:
#!/bin/sh

PATH=/usr/texbin:/usr/local/bin:$PATH export PATH cd "dirname "$1""
latexmk -c "basename "$1"" The only change is that latexmk is called with a -c option, so that it will clean up the auxiliary files, leaving the output PDF. I saved the script as cleanupaux.sh. Second, we'll look at the AppleScript. It becomes: tell application "SubEthaEdit" if exists path of front document then set latexFilePath to path of front document set modeResources to resource path of mode of front document else --Unsaved document, so LaTeX not run on it and can just return return end if end tell set cleanupScript to quote & modeResources & "/Scripts/shell/cleanupaux.sh" & quote & space & quote & latexFilePath & quote do shell script cleanupScript on seescriptsettings() return {displayName:"Clean Up Auxiliary Files"} end seescriptsettings Again, the changes are minimal. For typesetting, it mattered whether the front document was saved; here, it is only necessary to check whether the document has ever been saved. If it has, we run the shell script to clean up the auxiliary files, but if it hasn't, then LaTeX must not have been run on it so we just quietly do nothing. The seescriptsettings handler is simplified, as well. All that remains is a displayName, which appears in the mode menu. There seems to be little reason to have either a keyboard shortcut or a toolbar item, since the task is infrequent. The clean-up done by latexmk is fairly conservative. It only eliminates the auxiliary files from the specifically named document (in our case, the front document in SEE), and not from other files that are included. Further, it doesn't clean up absolutely everything, since different LaTeX packages can create files of their own which latexmk doesn't recognize. My feeling is that being conservative here is appropriate, as we don't want to accidentally delete something important while getting rid of the usual suspects. ## Sunday, July 15, 2007 ### Behaving Stupidly in Groups I was only going to post the once concerning the MacUpdate promotion, but I just can't resist. The current state of the promotion provides such a beautiful illustration of how making good individual choices can lead to perverse large-scale behavior. Thinking it through also leads to such an interesting optimal strategy for purchasing and whether or not to recommend that others purchase the bundle. Keep in mind, this is coming from someone that has already described the bundle as a great deal. Right now, the promotion can fairly be described as not going well. There are fewer than two days left of a nine-day promotion, and the number of sales is at about 3300. It looks like sales are going to limp along and just fail to reach the unlock point of 4000 sales for Intaglio. There was clearly an expectation of at least 10,000 sales, which is where the final application, TechTool Pro, would have been unlocked. I argued in the previous post that the entire system of unlocks is ill conceived, putting a strong disincentive on buying early, even though early sales are needed. As well, there originally was a system of invitations that benefitted not the sender of the invitation, but the recipient, providing further encouragement to wait before purchasing; the invites have since been fixed to reward the sender and recipient both. To provide an example of where the problem comes in, consider Intaglio. People have already posted comments on the promotion site to the effect that they will buy once Intaglio is unlocked. How many people are waiting for that? The bundle could be viewed as getting Intaglio, a well-regarded program that costs$89, for $50 with a bunch of other applications thrown in for free. It must be tempting, but, really, why should they buy it without knowing for sure that Intaglio will be unlocked? If enough people make that decision, none of them get the program, even though together they could have provided the needed number of sales. The group behavior seems stupid, but the individual behavior is completely sensible. Given the state of the sales, I think it worth considering the optimal strategy for those who have already bought the bundle, and for those who are thinking about buying the bundle. The optimal strategy for MacUpdate is indifferent to me; I see no reason to care, except in how it influences the benefits I will get from the promotion. Let's focus first on those who, like me, have already bought the bundle. We'd like to get as much more added to the bundle as possible, since it's all just free for us at this point. At first, it looks like we should encourage people to buy the bundle, so as to unlock Intaglio, at least. However, Joel Mueller, one of the organizers of the promotion, posted (as MUeller) a comment on 13/7 at 4:04 pm: We still haven't pulled out our big guns yet. We wanted the community to pull through first. Do not loose [sic] hope. We have every intent to unlock every app in this bundle. Interesting claim! Those "big guns" must be really something, right? Let's assume that they are enough to cause enough sales to at least unlock Intaglio. However, it does mean that there are some nice additions to the bundle which they're holding back. This in turn means that encouraging people to buy before those "big guns" are made available is pretty much a fool's game. We should encourage people to wait, hopefully getting both the "big guns" and unlocking Intaglio and TechTool Pro. In passing, I think Intaglio is quite possible, but doubt TechTool Pro will be unlocked. The same thinking applies to those who have already decided to buy, but haven't yet: they should wait to be sure that MacUpdate makes the "big guns" available. The same goes for those who are waiting to buy until, e.g., Intaglio is unlocked: they should wait, both to be sure that Intagio does unlock and so as to get the "big guns". I can see no reason for prospective buyers not to wait, at this point. There isn't a sufficient rate of sales to be at all sure that Intaglio will unlock; TechTool Pro is a pipe dream. There are some extras that haven't been offered yet. What appears to be the best case right now would be for sales to tank completely, pretty much forcing MacUpdate to offer some serious incentives with enough time left for Intaglio to unlock. The combination of supposed incentives in the promotion are pretty tragic. Each one has actually been a disincentive to early purchasing, basically killing any chance of enough sales to unlock the "crown jewel" of TTP. I must admit that I'm puzzled how MacUpdate could have gotten all of this so wrong. Could they actually have believed all the marketing dross about "the Mac community" on the promotion web site? There really isn't a relevant community there, just potential customers who'll make decisions that are right for them, not for some mythical community. It is not exactly a secret that people make choices for individual benefit can lead to perversely contrary results in the large. I will offer up a thought on what MacUpdate's strategy should be, although I won't put much effort into it. You want to sell as many as possible, so offer those "big guns," do it fast, and make clear that there's nothing else. So long as there is reason to think you're holding back, you're providing incentives to wait, killing sales to those who would buy if Intaglio were unlocked. As a closing note, do remember this is from someone who's already bought the bundle and thus has every reason to hope for a successful promotion. If I'm concluding that it would really be best for sales to die off, and fast, then there's something quite wrong with the incentive structure. ## Friday, July 13, 2007 ### A Nice Deal on Software (but a Bad Idea?) Right now, MacUpdate is running a great promotion, with a bundle of useful programs at a good price. The promotion is obviously based on MacHeist, but the character of the bundle is different. The programs in the MacUpdate bundle are selected based on the best-selling previous promotions, which makes the bundle maybe less flashy, but probably more useful overall. I've bought the bundle, and hope enough others will buy in order to "unlock" all the applications. That said, the promotion is appropriate to this blog for a much different reason. The promotion has an odd property that there are a number of disincentives to buying it early, but that it really requires early purchases to make it successful. There are seven apps to start, with three others that get "unlocked" if enough people purchase. So, if you buy early, you risk not getting the "locked" apps if the bundle doesn't sell well. Also, there was originally a system where, after buying, you could send an invitation to others, who would get a one-year paid membership to MacUpdate. While the benefits of that membership are pretty marginal, it's another reason to put off purchasing -- someone might send you an invitation, after all. Happily, this invitation system has been corrected by now. The promotion thus seems to have a Nash equilibrium for the "don't buy" state. While I didn't pay much attention to MacHeist, largely because I'd already registered the only programs in the bundle that were of interest to me, it would also have had such a Nash equilibrium. It is clear enough that MacUpdate based their promotion on the success of MacHeist, but is this really a good idea in the long run? Update: I think that the final paragraph might need to be clarified a bit. I mention that MacHeist was successful, and also that it had the same sort of Nash equilibrium that the MacUpdate promotion features. It might seem strange that I'm pointing this out as a problem for MacUpdate, when MacHeist was successful. In short, I'm arguing that MacHeist was successful despite the "unlock" portion, and certainly not because of it. Further, claims that MacHeist was successful are true in absolute terms, but do not validate the unlock idea; it could well be that MacHeist would have sold more without the unlocks. ## Thursday, July 12, 2007 ### SEEing LaTeX 7: A Brief Digression to Build Tools There are starting to be enough scripts for the LaTeX mode (some not yet described!) to justify automating the construction and installation of the mode. My first thought was make, unsurprisingly. There is a Makefile mode on the Coding Monkeys site, but it turned out to be a little disappointing. Not that it was bad, per se, just that it could be more. The existing mode highlights the syntax, and that's about it. It doesn't even automatically set the mode if you open a file named "Makefile"; you have to do that by hand. It wasn't very hard to extend the mode a bit. I added a ModeSettings.xml file to the bundle, specifying that files named "Makefile", "makefile", and "GNUmakefile" should be associated with the mode. The scripts for the LaTeX mode were easy to adapt into a form that would run make on the current SubEthaEdit document. It was necessary to add a little to the AppleScript portion, so that the results of running make would be reported, but that was straightforward. Unlike earlier installments in this series, I'm not going to present any of the scripts here. I see nothing more to do with the Makefiles mode, so I sent it to the Coding Monkeys. Once it's available on their site, anyone interested can download the mode and examine the scripts. ## Thursday, July 5, 2007 ### SEEing LaTeX 6: Typesetting Up to this point, I've written about composing LaTeX in SubEthaEdit, but not said much about invoking LaTeX to typeset the document. What I'd been doing was to run latexmk in a Terminal. Latexmk has the nice feature that it will run latex repeatedly until the document is ready, instead of having to do it repeatedly yourself. It also handles bibtex. Maybe best of all, you can set it to a continuous preview mode, which sets latexmk to watch your LaTeX file, recompiling it whenever you save changes you make; if you use a PDF previewer, like PDFView, that can reload the document whenever it changes, you can just set latexmk going and pretty much always have an up-to-date PDF ready to examine. More typical is to have a command in your editor that typesets the LaTeX document and sends the resulting PDF (or, if you must, dvi) file to a previewer. While it may lack the sheer coolness of the continuous preview that latexmk provides, it's a lot more natural and probably just as effective. Let's add that to SubEthaEdit now. Let's also start saving some typing by referring to it as SEE. The strategy will be to write a shell script to handle the typesetting, and an AppleScript to get needed information from SEE and feed it to the shell script. The shell script is easy, but does something that would be pretty awkward in AppleScript. The combination of shell and AppleScript is a useful way to take advantage of the power of Unix with data from an application. The shell script takes a single argument that is the path to the LaTeX file. First, we set a PATH that includes the directories for TeX (TeXlive, in my case, so /usr/texbin) and latexmk (/usr/local/bin/). The rest of the script then just changes to the directory for the LaTeX file, and calls latexmk to do the typesetting. The script is simple: #!/bin/sh PATH=/usr/texbin:/usr/local/bin:$PATH
export PATH

cd "dirname "$1"" latexmk -pv -pdf -quiet "basename "$1""

The trickiest part was getting the quoting right for the arguments to cd and latexmk. They may look excessive, but all those quotes are necessary!

A copy of the script goes into the LaTeX mode bundle. I put it at ${RESOURCES}/Scripts/shell/buildlatex.sh, where RESOURCES refers to the Resources folder in the bundle. The executable bit of the script is set. Now, let's look at the AppleScript. It's first going to save the document, if possible and necessary, since we'll normally want to see the effect of changes to a LaTeX document. We then extract the path to the file from the document, and the path to the shell script from the mode. These we glue together into a string that invokes the shell script on the document, and then we use do shell script to run it. Here's the script: tell application "SubEthaEdit" if exists path of front document then if modified of front document then try save front document end try end if set latexFilePath to path of front document set modeResources to resource path of mode of front document else error "You have to save the document first" end if end tell set buildLatexScript to quote & modeResources & "/Scripts/shell/buildlatex.sh" & quote & space & quote & latexFilePath & quote do shell script buildLatexScript on seescriptsettings() return {displayName:"Typeset and View PDF", shortDisplayName:"Typeset", keyboardShortcut:"@b", toolbarIcon:"ToolbarIconBuildAndRun", inDefaultToolbar:"yes", toolbarTooltip:"Typeset and view the current document", inContextMenu:"no"} end seescriptsettings The structure of the tell block is based on the discussion at the end of the SEE scripting page. The string we construct to invoke the shell script once again has a lot of quoting; once again, it's necessary! The boilerplate in the seescriptsettings handler sets up a keyboard shortcut and a toolbar icon. I just used ToolbarIconBuildAndRun for the toolbar icon image; I don't know that it's a great choice, but I didn't have anything more appropriate. For the keyboard shortcut, I went with command-B. It seemed appropriate, since the same shortcut is used in the Objective-C mode for compilation. The Java mode uses command-B for syntax checking, but it's inconsistent with several others that use command-control-B for syntax checking. I'd really liked to have used command-R to override the HTML preview, which is useless for the LaTeX mode, but it doesn't work; SEE just refuses to assign command-R to the script. Consistency for different modes is important, so command-B it is. The combination works well, but isn't flawless. I have several items set in my .latexmkrc, which aren't, at the moment, handled in the LaTeX mode bundle. Also, latexmk seems to give an error due to bibtex if you have a bibliography file called without any citations; I haven't established the exact conditions, but they match a new LaTeX document with the templates I use! Also, the AppleScript is a little slow if the document needs to be saved. In fact, there is no need for testing whether the document has been modified; I only check because the try block for saving makes the script conspicuously slower. Those are relatively minor problems. However, there is a conceptual problem that has become apparent: SubEthaEdit provides no means to define a mode-dependent environment. Amongst other problems, it makes it quite hard to write scripts like the ones shown in this post that won't break on someone else's computer. It would be quite appropriate to simply include latexmk in the bundle, but that obviously won't work for TeX! So, what to do? Put in paths for every TeX distribution I can think of? It's simply bad design, and I don't see any easy way for users to adjust the environment to suit their own systems (and, no, I don't think an environment.plist file is an acceptable solution). ## Wednesday, July 4, 2007 ### SEEing LaTeX 5: Taking Stock Today, I opened SubEthaEdit and found that I have 23 days left on the trial period. Put another way, I've been using it to write LaTeX for a week. It seems like an appropriate time to assess where I'm at. Citations have not been satisfactorily resolved. I'd really like to have a keyboard shortcut that completes a partially typed citation. At the moment, I have the system services available in SubEthaEdit (and pretty much everywhere else, of course!), and copying and pasting from the reference list in BibDesk. It looks feasible to write an AppleScript to get a list of completions from BibDesk, which would do what I want. However, it would be necessary to select out the right bit of text preceding the insertion point, with correct handling of the cases where text is selected or not selected. It sounds very fiddly and time consuming, but not actually difficult. Since I am trying to test out as much as possible during the trial period, it seems best to leave this for now. On the bright side, it's not like I've actually lost anything that I had with TextMate, because the citation completion wasn't working right, anyway. Pdfsync has been successful. It was surprisingly easy, although there was a need to dig into UI Scripting. The scripts could use a little refinement to be more robust, but work nicely enough as they are. As a whole, the scripting dictionary for SubEthaEdit seems adequate. As is common for scripting dictionaries, there are oddities and omissions, but nothing show-stopping as of yet. The degree to which scripts can be made to look like toolbar items and menu items is rather impressive, actually. So, what's left to do? The main things are to have means for typesetting from directly in SubEthaEdit, cleaning up all the auxiliary files, and comments. Cross references within the document could be more directly supported, although this is low priority: I use some personal LaTeX macros that reduce the need for such support, SubEthaEdit completes words from within the document, and showkeys makes the keys visible. After that, I can't think of much that isn't just typing shortcuts, such as inserting environments, sectioning, and formatting. That's clearly possible with AppleScript, but time consuming to enter it all in. It doesn't seem that you can arrange the scripts into submenus, so it's undesirable to overdo this, anyway. ## Monday, July 2, 2007 ### SEEing LaTeX 4: More on Completions Earlier, I took a look at using BibDesk to get SubEthaEdit to complete citations in LaTeX files. After working with it a few days, I've learned a few more things about BibDesk. Unfortunately, not all good. There seems to be a rather unpleasant interaction between BibDesk's completions and SubEthaEdit's completions. Normally, SubEthaEdit injects some mode-dependent terms into the completion dictionary. For some modes, like Python, this is no big deal; most of the keywords in Python are normal English words, so they would be completed by the standard completion dictionary. For other modes, e.g., the Objective-C mode, it can make a more significant contribution; the Objective-C mode defines a large number of Cocoa class names, which you can see by typing NS and pressing F5. Also, and maybe more importantly, SubEthaEdit will search through the current file to find matches, so, e.g., variables you've defined will be completed. For LaTeX, that provides a way to have the labels for equations, figures, and the like to be completed; for user-defined macros to be easily referenced; and for names and technical terms that don't appear in the standard dictionaries to be completed. Using BibDesk's Autocompletion input manager disables SubEthaEdit's Autocompletion features. Apparently, any input manager that extends completions will have this effect, as the SubEthaEdit FAQ notes that TextExtras will stop SubEthaEdit's Autocompletions from working. With TextExtras, that wouldn't be so bad, since it provides completions of its own, but the tradeoff with BibDesk is more extreme. You can have citations and, interestingly, the \ref and \pageref commands for cross-references completed, but lose completion of the terms in the document, whether it be LaTeX or something else. Or, you can have autocompletion of the terms in the document, but lose autocompletion of citations (cross-reference completion is handled just fine by completion of terms from the document). An early idea on how to resolve this was that I could install TextExtras, and use its completions. I used to use it, and liked it a lot, but gave up on it some time ago. I'm not sure exactly why, now, but I think it was because an earlier version of TextExtras conflicted with the then-new autocompletions in Mac OS X 10.3 Panther. Unfortunately, I haven't been able to connect to the TextExtras page to download it since coming up with the idea! In the end, I disabled BibDesk's Autocompletion input manager, it simply comes at too high of a cost. BibDesk has a number of system services, which allow citations to be inserted that way. It will have to do for now. A solution using AppleScript to get completions from BibDesk looks possible, but it seems best to make the issue clear now and solve it later. This is definitely a strike against using SubEthaEdit for LaTeX. Update: The same thing happens when BibDesk's input manager is loaded into other editors, too. In Smultron, you lose completion of words from the document; I'm not so familiar with Smultron, so I don't know if there are other features that get lost. It is truly a shame that one of the coolest features of BibDesk is also one that I just don't want to use. ## Sunday, July 1, 2007 ### SEEing LaTeX 3: From PDFView to SubEthaEdit In my last post, I presented an AppleScript that took us from a LaTeX document in SubEthaEdit to an appropriate portion of the corresponding PDF document in PDFView. This useful action is possible thanks to the magic of pdfsync. What's more, pdfsync can be used to work both ways. Let's take a look at how to go from a PDF document open in PDFView to the appropriate line in the LaTeX document. In PDFView, you can command-click in the PDF, which invokes a shell command to presumably take you to the right spot in your editor. This works very nicely in TextMate, for example. PDFView has a "command" text field and an "arguments" text field in its preferences. I don't really see why it's broken into two fields, but that's how it is, so that's what we'll work with. The arguments can include "%file" and "%line" tokens to indicate the file and line number, respectively. PDFView substitutes those tokens appropriately, and runs the script. SubEthaEdit has the see command line tool that lets us open a file. That will be our starting point. Shockingly, it doesn't have a switch to go to a particular line! We'll work around that with AppleScript. This will be needlessly ugly, I'm afraid. The see tool opens a file, and makes it the front document. That is the behavior we want for the document, so we'll start there and build a shell script to extend the behavior. We won't try to expose all the options of see in our script, instead just opening a file and going to a given line. We'll call the script seeline, and take its first argument to be the filename. The next step in the script is to set the selection in the front document to a line number given as the second script argument. This is easy enough with AppleScript, and is a fairly direct transcription of the English-language description. Unfortunately, that turns out not to be enough. The selection is set as desired, but the selection may not be visible! What's worse, there is nothing in SubEthaEdit's AppleScript dictionary that lets us scroll the view as needed. SubEthaEdit does have a "Jump to Selection" item in its "Find" menu. We could just hit command-J after PDFView transfers us to the LaTeX document in SubEthaEdit, I guess, but it is inelegant, at best. Instead, let's try something else. AppleScript can be used to script the user interface. You may need to first open the AppleScript Utility (why isn't this a preference pane, anyway?) and check the "Enable GUI Scripting" box. We can then use System Events to directly work with the menus of SubEthaEdit, choosing the "Jump to Selection" item. Taken all together, we get a script: #!/bin/sh # # Brings document to front in SubEthaEdit, opening if necessary, and # selects given line. # #$Id: seeline.sh,v 1.4 2007/07/01 18:28:31 mjb Exp $/usr/bin/see "$1"
/usr/bin/osascript > /dev/null <<ASCPT

tell application "SubEthaEdit"
tell front document to set selection to paragraph $2 end tell tell application "System Events" tell process "SubEthaEdit" tell menu bar 1 tell menu bar item "Find" tell menu 1 click menu item "Jump to Selection" end tell end tell end tell end tell end tell ASCPT All the AppleScript is included as a here document, which prevents lots of trouble with how the shell processes quotes and other characters. I'm not pleased with using UI scripting. It seems fragile and likely to break with updated version of SubEthaEdit. Clearly, this should be an option for the see command line tool, which pretty much means it needs to be handled by the developers. Whatever my feelings on the aesthetics of UI scripting, the important question is something else: does it work? Yes, it does, and pretty well at that. I have saved the script as ~/Library/bin/seeline, and set the "Command" and "Arguments" in the PDFView preferences to '$HOME/Library/bin/seeline' and '"%file" %line', respectively. Command-clicking in the PDF takes me to the LaTeX file.

Edit: Fixed formatting of included script.

Update: As of version 3.0 of SubEthaEdit, the see command line tool has an option to go to a desired line.

### SEEing LaTeX 2: Opening the PDF in a Viewer

Getting completions for citations in SubEthaEdit is easy. Of course, someone else did all the work for us, so it should be easy! Let's try something a little more ambitious.

I generally use pdflatex. Thanks to pdfsync, a number of editors can integrate nicely with PDF viewers, albeit the viewers themselves must incorporate support for pdfsync. So, let's try to set up pdfsync support for SubEthaEdit. I'll focus on integrating SubEthaEdit with my current viewer of choice, PDFView. Sadly, PDFView appears not to be supported any more, but it's still useful and the basic approach should be the same for any viewer. For now, I'll just focus on going from SubEthaEdit to PDFView.

The mechanism for linking SubEthaEdit to PDFVIew will be AppleScript. You can have PDFView display a particular LaTeX line using AppleScript, which is just what we need. The strategy then is to get the line number for the selection in SubEthaEdit, figure out the file name for the PDF, and then tell PDFView to show the line number we obtained from SubEthaEdit. According to the SubEthaEdit scripting guide, we also need to include a seescriptsettings handler. Here, I present something simple, without working too hard to catch errors:
tell application "SubEthaEdit"
tellfront document

set lineNumber to startLineNumber of selection
set texFile to path
end tell
end tell

set pdfFile to (text 1 through ((length of texFile) - 3) of texFile) & "pdf"

tell application "PDFView"
activate
display tex line lineNumber of file pdfFile
end tell

-- SubEthaEdit settings

on seescriptsettings()
{displayName:"Show in PDFView", shortDisplayName:"PDFView", keyboardShortcut:"^~@o", toolbarIcon:"ToolbarPDFView.png", inDefaultToolbar:"yes", toolbarTooltip:"Opens PDF for document in PDFView", inContextMenu:"no"}
end seescriptsettings

I saved the above script as a compiled script into a copy of the LaTeX mode. Now, for a LaTeX document, the Mode menu in SubEthaEdit shows a script called "View in PDFView" which can be activated by a keyboard shortcut. It works well.

I also added an image to the LaTeX mode bundle to provide a toolbar item. I encountered some difficulties with this. The description in the scripting guide isn't very specific, it really just says to put images in the bundle. I got an appropriate image by copying the icon from the PDFView application bundle, and converting it to PNG (since that's what all the other images in SubEthaEdit mode bundles were). This didn't work. It took me some time to discover that the toolbar icon cannot be any size; the 128 by 128 pixel image I had simply didn't show up. Downsizing it to 32 by 32 using ImageWell solved the problem, providing a nice toolbar item. Of course, I normally leave the toolbar hidden, so I doubt I'll be using it much, but it is good to know how that works.

The script has a couple of oddities and shortcomings. The tell block for SubEthaEdit needs to get the selection and path for the front document. However, the scripting dictionary for SubEthaEdit has both documents containing windows and windows containing documents. Is tell front document the right thing to do? Should it be tell document of front window? Or maybe something else?

Also, I don't check to see if the document has been saved. I'm not really sure what the right solution is: unsaved changes won't be reflected in the PDF, anyway, so should I care? I'll revisit that later, assuming that I decide SubEthaEdit is suitable for my LaTeX needs.

Nor do I check to see if there is a document open at all. As far as I can tell, this is not an error. The script is mode dependent. Since the LaTeX mode is only active if there is a document open, there is thus no need to check.

The transformation of the LaTeX file path to a PDF file path is not done well. It should really be improved by properly splitting off the file extension, instead of just chopping off the last three characters and assuming we've gotten the file extension. While it is probably OK for LaTeX, I'm not sure if it could cause any problems. Again, this is something to fix later, once a more complete picture of editing LaTeX in SubEthaEdit takes shape.

The tell block for PDFView is weird. There aren't any changes I'd make, but it is just strange. If you open the script in Script Editor and compile it, the display tex line lineNumber of file pdfFile becomes display tex line lineNumber file pdfFile, which is syntactically invalid. However, you can run the script without first compiling, and it works fine. Which is really weird, because the script has to be compiled before running it, so it works once but fails the second time you run it. My solution was to do the editing in SubEthaEdit, compile it in Terminal using osacompile, and not worry about the matter. I suspect that the scripting dictionary in PDFView should just be considered in error, even though it can be made to work.

Next, I'll look at going the other direction, from PDFView to SubEthaEdit. A quite pleasant environment already looks possible.

Edit: Fixed formatting of included script.