[TxMt] [Latex] Compiler selection logic

[Charilaos Skiadas]

On Apr 15, 2007, at 4:33 PM, Robin Houston wrote:

> Hi Haris,
>
> Thanks for the reply.
>
> On 4/15/07, Charilaos Skiadas <skiadas at hanover.edu> wrote:
>> Not sure we should really distinguish between mytex and mylatex. Any
>> use cases where both are needed as options?
>
> I agonised over this. The reason I proposed what I did is not because
> I think it's crucial to have both, but because I don't think the  
> simplification
> (of only supporting one) is important enough to break TeXShop  
> compatibility for.
>

> Perhaps we could just document one of them. That way we
> a) don't overburden the user with possibilities, but
> b) still meet the expectations (and support the documents) of someone
> switching from TeXShop.

I suppose what I was thinking was that we would accept mytex as an  
option, but behind the scenes convert it to mylatex. I suppose that  
might break some scripts, but it would simplify matters, especially  
with regards to TM_LATEX_MYTEX. Are there really people using mytex?  
If there are, then by all means we should support it. But yeah, we  
should probably document only one option. (of course, just talking  
about it here we are essentially documenting both options ;) ).

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

>> Also, what exactly do we mean when we say "compilation route is
>> 'latex' "? latex would produce a dvi file. Do we then convert it to
>> pdf, and if so how?
>
> Yes, we convert it to PDF. As for how to do this, perhaps:
> 1. Look for simpdftex, and use it if present.
> 2. Look for altpdflatex, and use it if present.
> 3. Use tex, dvips, ps2pdf, if all are present.
> 4. Give up with an error.

Hm, not sure the presence of these is what we should be using. I have  
all three in my system, but not really any preference for any of  
them. I don't even know the difference between them.

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?

>> Also, should the user have a way of specifying that they want dvi
>> output instead of pdf output?
>
> I reckon that if someone wants that (or any other weird combination  
> of things), they can just write a custom compilation script and use  
> mylatex.

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

>>> > 1. Use the %!TEX TS-program specification in the source file.
>>> > 2. Use the %!TEX TS-program specification in the master file.
>>>
>> Actually those 1,2 are really one, using the options.sh/options.rb
>> script/library. There might be other files between the source file
>> and the master file, and those should be looked at as well. Also keep
>> in mind that there are multiple ways to define what the master file
>> is (I think options.sh/rb takes care of that).
>
> Hmm. My ordering was quite careful here: options.sh actually does  
> it the wrong way round, i.e. the master file spec over-rides the  
> one in the source file itself! The Typeset & View script justifies  
> this with the comment:
>
>   # Yes, this means options in master files override options in the  
> individual file
>   # this may not exactly be ideal, but it's easiest. Show me a file  
> structure that this
>   # is a problem for, and I'll show a poorly-designed LaTeX file
>
> which I think speaks for itself. (I'm not even convinced by the  
> "easiest": it's not exactly hard to do this properly!) As for  
> chaining more than two files: if you consider that an important  
> feature, then consider it done.

I actually think the master file should be taking precedence here,  
but admittedly I can't really envision a situation where it is useful  
to have the %!TEX info not in the master file, but in the included  
files instead. Otherwise people would have to add the %!TEX  
specification in any new file that is to be included in the master  
file, and which compilation method is employed depends on which file  
you are in and not which project you are working on, which again  
feels wrong.

But perhaps I've missed some use cases overall.

Kevin Ballard is actually the one who wrote that script, so perhaps  
he can weigh in on his rationale.

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). I think TeXShop also uses another method  
through some hidden file, but I'm not too sure.

>> Looks good overall.
>
> Great! When we've reached agreement on all the details, I'll get  
> coding.

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?

> Robin

Haris Skiadas
Department of Mathematics and Computer Science
Hanover College