[TxMt] [Latex] Compiler selection logic

[Charilaos Skiadas]

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 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.

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