[TxMt] [Latex] Compiler selection logic

[Robin Houston]

On 4/15/07, Charilaos Skiadas <skiadas at hanover.edu> wrote:
>
> Are there really people using mytex?
> If there are, then by all means we should support it.


This is the real question, and I don't know the answer! (Which is why I
proposed to err on the side of caution). But I'm happy to try it with just
one, and see if anyone complains.

Ideally we should have ConTeXt as an option there as well.


That sounds like a good idea. "%!TEX TS-program = context" doesn't seem to
have any effect on TeXShop though.

I would expect the user should be able to also make a choice here.
> Question is how to make is as seamless as possible. What are the
> difference between the three options? Is there a reason you ordered
> them this way?


Sure there is.

simpdftex is the currently-recommended script. On my (teTeX) system,
altpdflatex just prints "This script has been deprecated. Please call
simpdftex instead". So that's a good reason to use simpdftex if it exists,
in preference to altpdflatex. And this is definitely preferable to calling
dvips/ps2pdf by hand, because many years of debugging have gone into
simpdftex, and it takes care of lots of subtle issues that are hard to get
right.

Well they could, but the Typeset&View script has a viewing component,
> which will be expecting a pdf file, no?


I see what you mean. I still wonder whether the extra complexity is worth
it, though. Perhaps we could just have TM_LATEX_VIEWER=none disable the
viewing component, and the user could invoke her viewer of choice from
within the mylatex script? It's typically only one extra line of code, and
this seems likely to be a fairly unusual situation.

I actually think the master file should be taking precedence here,


Perhaps you're right. I think I missed something important.

I was imagining a situation where you have a book, say, and one
chapter uses something like PSTricks, so you want to use dvips
for that one chapter, but not for anything else. Of course the problem
with this line of thinking is that actually the whole book is being
compiled with a single command, by compiling the master file,
so it probably is better to use the master file's spec consistently.

Okay, I'm convinced. But I think that if the current file specifies
something that conflicts with the master, we should print a warning
because this might not be what the user intended.

We should probably also clear out the process with which we locate
> the master file, if any. There is TM_LATEX_MASTER and the %!TEX root
> specifications. I am in favor of TM_LATEX_MASTER as first choice, and
> the root specifications next (again so that the choice is controlled
> on a per-project basis).


That makes sense, though again I think we should warn if there's a root
setting in the file that conflicts with the one we're using.

I think TeXShop also uses another method
> through some hidden file, but I'm not too sure.


Indeed it does. Thanks for reminding me about that.

Btw, were you going to keep it in its Bash Shell form or write it in
> something like Ruby. I have a semi-working version of the current
> script in Ruby, I'll send it to you offline. Perhaps we can build on
> that?


I was thinking of keeping it as a shell script, but if you've already
done some of the work in Ruby, I can stick to Ruby instead.

Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20070415/1937f4d0/attachment.html>