[texworks] script parameters

[Casey P. Johnson]

> Hi,
> You suggest to improve the overall TeX user experience, this is always a
good idea, but here ,this is not stricto sensu a TeXworks issue. IMO, it
is not a good idea to control the user interface from the tex source.
> In general this is considered good practice to clearly separate the
tasks,
> and the tex source should never know anything about latexErrors.js.
Moreover, when sharing documents, using \typeout or \wlog for such a
purpose would be considered as a pollution.
> Finally, if you decide to change in latexErrors.js the way parameters
are
> read, you will have to edit all the tex sources.
> There must be another way to pass parameters from TeXworks to
> latexErrors.js.
> BTW, if you think of a dedicated format of strings in the log file to be
parsed by latexErrors.js (and possibly plain, context or so)
> you might ask the TeXLive developers for a dedicated primitive in pdftex
(and xetex, luatex)
> It is something rather easy to implement, the benefits would be great
IMO.
> For example
> \notifylog{TYPE}{COMMENT}
> would print to the log something like (to be improved)
> TYPE:file:line:COMMENT
> end of TYPE
> Jérôme


I agree that it would be nice if there were a simpler way to set
parameters in TW and pass them to a script (or to set parameters in one
script and pass them to another). In fact, I casually suggested this a
while back in Issue 271.

With latexErrors.js and texworks.sty I am just trying to find a way to
work around the current limitations. I want to be able to adjust the
verbosity because most of the time I just don't care about, e.g.,
"Marginpar on page XX moved."  When doing the final tweaking of a
document, though, those will be more important.  With the current system,
I can either edit the Javascript or the LaTeX source. Since I am already
editing the LaTeX, it seems the lesser of the two evils.

You raise some important issues, though. It is true that it would be best
for the LaTeX source to be editor-agnostic. Since I use \typeout, at least
there is no danger of compatibility issues if using an editor other than
TW. Even if the implementation were to change and the script wouldn't
behave as desired, at least it wouldn't generate any errors that prevent
correct compilation.

So, the remaining issues are the pollution you mention and compatibility
issues that arise if the implementation changes. In the case of
latexErrors.js, I don't see these as real problems, as I don't envision a
LaTeX document riddled with commands like \TexWorksWarnings.  Such a
command, if used at all, would only appear once or twice in a given
document (probably in the preamble). So, pollution would be minimal. Also,
such a command would only appear in a document that is actively edited
(why would \TexWorksWarnings be needed in a "complete" document?), so if
the implementation were to change it would be easy to fix the LaTeX
source.

The reality is that I expect most documents would not include texworks.sty
at all. In fact, I may end up not using it much myself. Rather, the user
would open latexErrors.js once, select their preferred level of verbosity
there and only if they wish a specific document to deviate from their
preference would they include texworks.sty.

On the other hand, I can see that for scripts in general this sort of
mechanism would be undesirable.  For example, if these sorts of references
were used in numerous places throughout a document by a single script or
by several scripts, it could result in a great deal of pollution (though
can it really be polluted if it already looks like this?

(see the transcript file for additional information)<C:/Program Files
(x86)/MiK
TeX 2.8/fonts/type1/public/amsfonts/cm/cmbx10.pfb><C:/Program Files
(x86)/MiKTe
X 2.8/fonts/type1/public/amsfonts/cm/cmcsc10.pfb><C:/Program Files
(x86)/MiKTeX
 2.8/fonts/type1/public/amsfonts/cm/cmex10.pfb><C:/Program Files
(x86)/MiKTeX 2
.8/fonts/type1/public/amsfonts/cm/cmmi10.pfb><C:/Program Files
(x86)/MiKTeX 2.8
/fonts/type1/public/amsfonts/cm/cmmi5.pfb><C:/Program Files (x86)/MiKTeX
2.8/fo
nts/type1/public/amsfonts/cm/cmmi6.pfb><C:/Program Files (x86)/MiKTeX
2.8/fonts
/type1/public/amsfonts/cm/cmmi7.pfb><C:/Program Files (x86)/MiKTeX
2.8/fonts/ty
pe1/public/amsfonts/cm/cmmi8.pfb><C:/Program Files (x86)/MiKTeX
2.8/fonts/type1
)

So, I think I now agree that this technique should be avoided. It is easy
enough to remove the few lines from latexErrors.js that provide this
functionality. I will begin trying to come up with a better way to do
this.

Thanks for the input.

Casey