Sorry for a very delayed answer, lots of things have been going on here.
On Apr 15, 2007, at 6:28 PM, Robin Houston wrote:
On 4/15/07, Charilaos Skiadasskiadas@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.
Let's keep it with two for the moment.
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.
That's TeXShop's problem perhaps ;)
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.
Sounds good then.
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.
If synchronization is required, then leaving that to the user is expecting too much I think.
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.
As long as it's a discrete warning, then that sounds good.
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.
Sounds reasonable.
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.
A main problem with the Ruby version atm is that it doesn't play very well with the logfile parser, which is a python script at the moment. The main problem is that for some reason currently the python script must finish before the ruby version can print its output, and I couldn't fix it, but perhaps someone else could. Not sure in any case how important it is for the output to be streamed into the HTML window, instead of appearing all at the end, but I suppose in long compilation processes it might help.
I had plans on working on rewriting the parser in Ruby and improving it in the process, but haven't had time for it as yet.
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College