[texworks] %!TEX root =

[Jonathan Kew]

On 1 Jan 2009, at 19:10, Joseph Wright wrote:

> Jonathan Kew wrote:
>> It's supposed to work. (See the function
>> TeXDocument::findRootFilePath(). It uses a regexp to allow  
>> flexibility
>> about spacing, perhaps that's why you didn't find it with a simple  
>> search.)
>>
>> AFAIK this has been working for others, so if it's not working for  
>> you,
>> please try to come up with a precise example scenario that we can  
>> check.
>
> Ah, I see the issue.  I have a sub-doc with !TEX root = <whatever>,  
> and
> in the main file !TEX program  = pdflatex. However, the default engine
> is pdfTeX.  So when I Ctrl+T in the sub-doc, TeXworks ignores the  
> engine
> spec. in the main file and tries to pdfTeX it.  Result: compilation  
> fails.
>
> I'd expect the engine spec in the main file to be respected here, I  
> think.

Ah yes... I've realized this could be an issue.

What if you have conflicting "program = ..." specifications in the  
current file (sub-document) and the root document; which should be  
used then?

The way "program = ..." is handled in TeXworks is slightly different  
from TeXShop, if you're familiar with its behavior. In TS, any  
"program = ..." specification *overrides* the engine that's selected  
in the toolbar popup, so Cmd-T always uses what the file specifies. In  
TW, on the other hand, the "program = ..." specification initializes  
the popup to the chosen setting when the file is opened (or when the  
specification is edited), but if the user then changes it manually,  
the new choice will be respected.

This means that when you press Cmd-T (Ctrl-T), TeXworks relies on the  
toolbar popup to tell it what to do; it doesn't inspect the "program  
= ..." line at this time. And so the engine you get is the one that's  
selected in the window where you press Cmd-T.

I'm not sure if there's any approach to this that's clearly "best",  
within the model where you can have a number of files that may have  
differing metadata, and you also have a user interface where you may  
specify something different yet again. A full "TeX Project" model,  
where all the component files "belong" to a project, and metadata like  
this is carried at the project level rather than added to individual  
files, would make things clearer. This may be an option in the future,  
but I don't want to make it a requirement for using the program or for  
being able to include the engine choice in the source.

JK