Good to see interest in thea2 and fixing issues! Integrated. Replaced writeln/1 by `format(’~q.~n’, …) to guarantee proper quoting and a full-stop.
If you have more, could you use github pull requests? That makes changes tracktable and simplifies integration a lot (with less risk on mistakes).
Thanks, Jan – happy to use pull requests. But I’ll admit I’m a bit hazy on the proper (preferred) git process. Do I raise an issue first, and then create a separate branch (will need write access for that), and ultimately a pull request? (and are there naming conventions to be observed?)
I am no GitHub Jedi (I just coined that) but if the change is simple and a single file you need to find the file you need to change at GitHub SWI-Prolog site, e.g.
click the pencil icon for editing, you should be able to edit the file and then at the bottom add a reason for the edit and click Purpose file change I think that will do it. That is how I did this change.
See:
Editing files in your repository
Editing files in another user’s repository
HTH
Nice that there is a really simple route for small stuff. Notably handy for small documentation issues! The normal one, assuming you do your work on the sources obtained using git clone from github:
git checkout -b fix-for-xyz
<fix/extend/clean the code>
<commit using your favorite tool>
(repeat the two above as long as needed, preferably do not put
unrelated stuff in one commit)
git push origin fix-for-xyz
And github will reply with a link for creating the PR. If the PR is accepted and processed (with or without changes, do
git checkout master
git pull
git branch -D fix-for-xyzThanks, Jan – this reply is a wonderful succinct procedure that is worthy to go into some SWI-Prolog general guidance somewhere 
Great! I’ve also added Jan’s guidance to the SWI-Prolog Wiki, on the package how-to page (which has a section on how to use github): https://eu.swi-prolog.org/howto/Pack.txt