[texworks] New version 302/303

[Jonathan Kew]

Thanks for all your investigation, Tomek....

On 5 Jun 2009, at 17:34, T T wrote:

> I've done some more forensic work on this issue. I've added to  
> texworks.ini:
>
> binaryPaths=
>
> This shows in the preferences dialog as an empty slot. With this in
> place everything works, i.e. my test call to 'cmd /c path' returns the
> PATH with leading ';'. If I have:
>
> binaryPaths=,
>
> then I get two empty entries in the dialog and 'cmd /c path' returns
> the PATH with two leading semicolons, and so on. Now, if I remove all
> those empty slots from the preferences, then I get the following entry
> in texworks.ini:
>
> binaryPaths=@Invalid()

Curious, but I guess this is how Qt represents an empty stringlist in  
the .ini file (to distinguish it from a list containing a single,  
empty string, as in your first example).

> With this in place the call to 'cmd /c path' (or any other tool) fails
> with program not found. This means that, if binaryPaths is @Invalid(),
> adding the PATH to it fails (at least on Windows). Here's the relevant
> piece of code from TeXDocument::typeset():
>
>  QStringList binPaths = TWApp::instance()->getBinaryPaths();
>  QStringList env = QProcess::systemEnvironment();
>  QMutableStringListIterator envIter(env);
>  while (envIter.hasNext()) {
>          QString& envVar = envIter.next();
>          if (envVar.startsWith("PATH=")) {
>                  foreach (const QString& s,
> envVar.mid(5).split(PATH_SEPARATOR, QString::SkipEmptyParts))
>                  if (!binPaths.contains(s))
>                          binPaths.append(s);
>                  envVar = "PATH=" + binPaths.join(PATH_SEPARATOR);
>                  break;
>          }
>  }
>
> If binaryPaths key exists in texworks.ini, then its content is
> returned by TWApp::getBinaryPaths() but if it doesn't exist then the
> result of TWApp::setDefaultPaths() is returned.

Right.

> Now the question is:
> what TWApp::setDefaultPaths() returns if tex is not found on any of
> the predefined paths?

setDefaultPaths doesn't care whether tex (or anything else) is  
actually present in the predefined paths; it just returns the list of  
paths, it's the typeset() function that will look for tools.

> If the return value is @Invalid() as for
> binaryPaths, then we have the same problem.

setDefaultPaths shouldn't ever be returning an empty list, though even  
if it does, an empty list ought to be harmless.

> Another wierd thing I've noticed is that, w/o binaryPaths in
> texworks.ini and using e.g.
> PATH=..;D:\Software\LocalApps\miktex27\miktex\bin;C:\Windows\system32,
> my test call returns (rev.303):
>
> PATH=D:\Software\PortableApps\PortableApps\TeXworksPortable;..;D: 
> \Software\LocalApps\miktex27\miktex\bin;C:\Windows\system32;..;D: 
> \Software\LocalApps\miktex27\miktex\bin;C:\Windows\system32
>
> Note that the original PATH is repeated twice in the one passed to the
> spawned process, which should not happen, because of the condition
> (see above):
>
>     if (!binPaths.contains(s))  binPaths.append(s);
>
> So something is not right here.

Rev 303 did not include that condition, it unconditionally added the  
PATH in typeset(). This was revised in r.306. So this part, at least,  
is not a mystery.

> Unfortunately I don't know enough
> about Qt to troubleshoot this any further but I hope I narrowed this
> down sufficiently that someone can figure this out now. Jonathan, does
> it make any sense to you?

Not really! :(  When you have cleared all the paths from Preferences,  
so that texworks.ini has binaryPaths=@Invalid(), what paths show up in  
the Program Not Found alert? I guess you'll need a new build from  
Alain to see the new version of that alert, which lists the final list  
of paths.... I'm very curious to see what happens with that.

JK