On 4/15/07, Charilaos Skiadas <skiadas@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

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.