As we've discussed before, the current compiler selection logic (in the Typeset & View command) is a bit of a mess. Below is a suggestion for how it might be rationalised. Once we've agreed on a plan, I'm happy to implement it.
One complication is that it's sometimes useful to have compilation under the control of a custom script – either one that you've written for your specific project, or a generic compilation tool such as latexmk. The way that TeXShop deals with this is to have special program-designators "mytex" and "mylatex", which signify that a user-specified compilation script should be used. I propose that we adopt this mechanism.
The first task is to decide on the compilation route to use. This will be one of: tex, latex, pdftex, pdflatex, xetex, xelatex, mytex, mylatex. I propose trying the following things, in order:
1. Use the %!TEX TS-program specification in the source file. 2. Use the %!TEX TS-program specification in the master file. 3. Use the value of the $TM_LATEX_PROGRAM variable. 4. Sniff for \usepackage commands that suggest (DVI)latex/xelatex should be used. 5. Default to pdflatex.
If the resulting value is mytex/mylatex, then: 1. Use the script specified in the variable $TM_LATEX_MYTEX or $TM_LATEX_MYLATEX, 2. Use the script specified in the TeXShop configuration, if any: defaults read TeXShop TexScriptCommand defaults read TeXShop LatexScriptCommand 3. Give up, explaining why.
So, the variables $TM_LATEX_COMPILER and $TEX_PSTRICKS would no longer be used. For backwards compatibility, we could continue to allow the value of $TM_LATEX_COMPILER to trump all other considerations (perhaps with a warning in the compilation window to the effect that this variable is deprecated, and explaining the new way to do it).
Any thoughts?
Robin
Hi Robin,
thanks for working on this. On Apr 13, 2007, at 6:51 AM, Robin Houston wrote:
As we've discussed before, the current compiler selection logic (in the Typeset & View command) is a bit of a mess. Below is a suggestion for how it might be rationalised. Once we've agreed on a plan, I'm happy to implement it.
One complication is that it's sometimes useful to have compilation under the control of a custom script – either one that you've written for your specific project, or a generic compilation tool such as latexmk. The way that TeXShop deals with this is to have special program-designators "mytex" and "mylatex", which signify that a user-specified compilation script should be used. I propose that we adopt this mechanism.
The first task is to decide on the compilation route to use. This will be one of: tex, latex, pdftex, pdflatex, xetex, xelatex, mytex, mylatex. I propose trying the following things, in order:
Not sure we should really distinguish between mytex and mylatex. Any use cases where both are needed as options?
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?
Also, should the user have a way of specifying that they want dvi output instead of pdf output? Or do we somehow sniff that out of the TM_LATEX_VIEWER setting?
- 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).
- Use the value of the $TM_LATEX_PROGRAM variable.
- Sniff for \usepackage commands that suggest (DVI)latex/xelatex
should be used. 5. Default to pdflatex.
If the resulting value is mytex/mylatex, then:
- Use the script specified in the variable $TM_LATEX_MYTEX or
$TM_LATEX_MYLATEX,
Consequently, I would think only one variable should be sufficient, namely $TM_LATEX_MYLATEX
- Use the script specified in the TeXShop configuration, if any:
defaults read TeXShop TexScriptCommand defaults read TeXShop LatexScriptCommand 3. Give up, explaining why.
So, the variables $TM_LATEX_COMPILER and $TEX_PSTRICKS would no longer be used. For backwards compatibility, we could continue to allow the value of $TM_LATEX_COMPILER to trump all other considerations (perhaps with a warning in the compilation window to the effect that this variable is deprecated, and explaining the new way to do it).
This sounds reasonable. I would definitely want backwards compatibility.
Any thoughts?
Looks good overall.
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College
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.
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.
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.
- 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.
Looks good overall.
Great! When we've reached agreeement on all the details, I'll get coding.
Robin
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
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 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.
Robin
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
On 4/25/07, Charilaos Skiadas skiadas@hanover.edu wrote:
Sorry for a very delayed answer, lots of things have been going on here.
Thanks for all this. I've been busy too, which is why I haven't written the code yet. I still plan to, unless of course someone beats me to it!
If synchronization is required, then leaving that to the user is
expecting too much I think.
Is there ever a good reason to preview DVI rather than PDF (in TeXniscope, I assume we're talking about)? I couldn't think of one, but I'm probably missing something.
Robin
On Apr 25, 2007, at 10:47 AM, Robin Houston wrote:
On 4/25/07, Charilaos Skiadas skiadas@hanover.edu wrote:
Sorry for a very delayed answer, lots of things have been going on here.
Thanks for all this. I've been busy too, which is why I haven't written the code yet. I still plan to, unless of course someone beats me to it!
If synchronization is required, then leaving that to the user is expecting too much I think.
Is there ever a good reason to preview DVI rather than PDF (in TeXniscope, I assume we're talking about)? I couldn't think of one, but I'm probably missing something.
I can't think of one either, but then again I haven't previewed in DVI for 2 years or so. Perhaps someone else prefers it though? Dunno.
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On 4/25/07, Charilaos Skiadas skiadas@hanover.edu wrote:
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,
Setting STDOUT.sync = true in the Ruby script appears to fix this problem.
Robin
-
Charilaos Skiadas -
Robin Houston