[texworks] Help files for Scripting

Stefan Löffler st.loeffler at gmail.com
Thu Jun 10 06:39:17 CEST 2021

Hi Henrik,

On 08.06.21 14:22, Henrik Skov Midtiby wrote:
> The system is now working ;-)

That's awesome news! It looks very good. I had thought about roughly the 
same idea, but you were much faster in implementing it :).

A few comments/questions/musings/suggestions:

*) My main concern with this method was that every commit is essentially 
"doubled", i.e. for every commit to the master branch there will be a 
corresponding commit to the gh-pages branch. This seems kind of wasteful 
and blowing up the git history. But I haven't found any good way around 
it, unless we find a system other than bookdown that is supported 
natively by GitHub Pages/Jekyll (which is ruby-based, I think). One 
"alternative" would be to create two separate repositories (one for the 
sources, and one for the output) rather than a single repository with 
two branches. The benefit would be that (naive) cloning of the sources 
would not download all versions of the html output, but at the (IMO 
high) cost of having two completely detached repositories.

*) Personally, I have come to preferring GitHub Actions over TravisCI. 
Functionally, they are pretty similar. I used to use travis for building 
TeXworks, until they abruptly introduced some quotas/usage limits a 
while back (plus their Windows version never worked for me, but that's 
irrelevant for the manuals). IMO, Github Actions also has the advantage 
of being hosted directly on Github, which might make some things 
(slightly) faster. There's also the possibility (with some trickery) to 
make "artifacts" available (such as, here, the latest pdf version of the 

*) The deploy script could potentially benefit from:
-) Commiting from the CI should ideally happen on behalf of the original 
commit's author
-) The case where files are deleted should be handled (probably 
something along the lines of `rm *` before copying over the book) - or 
is this handled and I missed it?
-) We should check if this gracefully handles all cases (e.g., does the 
commit fail if none of the output files have changed?) unless you have 
done so already

These are solely meant as suggestions for further improving the 
infrastructure, I fully realize that this is a first "proof-of-concept" 
right now.

On 08.06.21 16:45, Paul A Norman wrote:
> Would that be able potentially in the future to be set up under the 
> area that Stefan is looking at as suggested in his earlier postings – 
> do you think?

Yes, absolutely. We'd just have to migrate the repository - piece of 
cake (hopefully ;)).

> Downloading and producing locally and reposting resultant document(s), 
> seems a fair way to go.
> Would we use RStudio for production locally, or could we jump directly 
> to pandoc?

Building it locally would only be required for testing purposes. To way 
Henrik set it up, you'd ultimately only have to push (publish) the 
changed source files and all the output would be built automatically 
(whether with R or pandoc or any other tool; producing a website, a pdf, 
an e-book, or whatever).

> And I assume that a seperate project could conceivably handle the main 
> TeXworks manual?
> Or is there a case here, for just making the scripting API TwScript a 
> section of that TeXworks manual, or is it better to keep them both 
> separate from each other?

Personally, I would prefer to keep them separate/independent. The reason 
being that the target audience is probably very different: on the one 
hand a user trying to learn how to use TeXworks, who probably doesn't 
want to see pages upon pages of "technical documentation"; on the other 
hand a script programmer how doesn't want to have to skip pages upon 
pages about downloading, installing, and using TeXworks for the first time.

All the best,

More information about the texworks mailing list.