On Apr 15, 2007, at 4:33 PM, Robin Houston wrote:
Hi Haris,
Thanks for the reply.
On 4/15/07, Charilaos Skiadas skiadas@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:
- Look for simpdftex, and use it if present.
- Look for altpdflatex, and use it if present.
- Use tex, dvips, ps2pdf, if all are present.
- 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?
- Use the %!TEX TS-program specification in the source file.
- 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