CoCoA » CoCoALib

How many files are affected? How many would need to have new names?
We could try contacting the txt2tags people to see whether it is regarded as a bug (and if so, whether a fix might "soon" become available).

check for "warning" in CoCoALib.log: there are lots of problems with internal links, it seems (but only for me and not for John ?!??)

Splendid. I'll try this tomorrow.

Regarding the new version of doc/Makefile in the recent release CoCoALib 0.99800:

If a $(TXT2TAGS) resides in $PATH (i.e. the commented option near the beginning of the file instead of the hard coded path at which nothing is provided in the release), the checks if $(TXT2TAGS) is executable and readable

[ -x "$(TXT2TAGS)" ] && [ -r "$(TXT2TAGS)" ]; \
if [ $$? -ne 0 ]; \
#[...]

do not make much sense and prohibit that the documentation is built.

Anna Maria Bigatti wrote:

Ulrich von der Ohe wrote:

do not make much sense and prohibit that the documentation is built.

This (for this release) is actually intentional. We release the compiled documentation in different formats, but not the (external) tool to modify and re-create them.

I am not arguing that txt2tags should be included in a CoCoALib release. On the contrary, I want to use my txt2tags at /usr/bin/txt2tags. This has been no problem with CoCoALib-99718 (and earlier releases). Now it is much more of a hassle:

First, the standard ./configure && make gives a warning that it cannot find aux-txt2tags/txt2tags and does not create the documentation.

Obviously, I should exchange the comment sign in the following lines in doc/Makefile (which was not necessary with earlier releases):

##TXT2TAGS = txt2tags # if installed version is old enough
TXT2TAGS = $(AUX_DIR)/txt2tags

Expecting it to work now, I try again. But now make fails, since it finds out that txt2tags is not executable. Of course it is not (it does not exist in the current directory), but /usr/bin/txt2tags is and is perfectly valid.

Responsible for this are the lines:

[ -x "$(TXT2TAGS)" ] && [ -r "$(TXT2TAGS)" ]; \
if [ $$? -ne 0 ]; \
then \
echo; \
echo "***WARNING*** $(TXT2TAGS) missing ==> not creating/updating HTML documentation"; \
echo; \
exit; \
fi; \@

Deleting them leads to a working version.

In fact, which txt2tags (a few lines before) would have failed had my installed txt2tags not been executable or readable. (Incidentally, you might want to consider using POSIX 'command -v' instead of 'which'.)

I think this mixing up of txt2tags (in current directory) and in $PATH (like /usr/bin/txt2tags) is not intended.

the whole process of releasing the sources has been modified and might change further still.

Since you mention it: It seems to me that some files are missing in the new release (that were included up to the previous release 0.77918). I think such a problem affects building of the GUI, see #1393#note-13.

The main problem (for me) was that I had upgraded to Ubuntu 20.04, and this automatically upgraded txt2tags.
The new version of txt2tags gives errors when compiling the documentation.

An ideal solution would be to revise our documentation so that it works with the new versions of txt2tags, but do not currently have time for that.
As a temporary fix, I was planning on including a copy of the old version of txt2tags in the CVS tree.

As Anna said, we have recently revised the way of making source releases: the old way included some "private junk".
We are still unsure exactly what to include, and what the directory tree structure should be...

Ulrich von der Ohe wrote:

I have a (for me) working version with txt2tags 3.4. All the files I changed (relative to CoCoALib 0.99800, which requires more attention than the previous version) are attached.

It works!! Thanks Urlich!!
I am now using txt2tags/3.7_3, and the changes suggested by Urlich.
(I changed DocTeX, so that it keeps the date of the latex file, instead of "\today")

Now I fix the last bits, and make the source release.

As I'm in a rush I'll still leave the hardwired txt2tags in Makefile, but this will be better thought of very very soon.

2022-10-07: what is the status of this issue?

Are Ulrich's modifications already checked in?
Can the issue be closed?

What is the status of this issue? Is it advanced enough that we can close this week? (I hope so)

About a year ago, I created a PR on their repo (https://github.com/txt2tags/txt2tags/pull/244) targeting the v2 branch (which hasn't been updated since 2017). So I did not have high hopes that they would merge it.
However, out of the blue, they did merge it three weeks ago, as the first commit in more than five years.
Using this version (which is exactly the one I have installed now), everything seems to work fine, at least on my machine (on Windows).

What is the status of this issue?
Is it now resolved if one uses the updated txt2tags which Nico mentioned? Which version is that?

Let's try to download the new txt2tags, and test it.
Nico which version should we obtain?
Anna how do we test it?
I hope we can close this is in a few days :-)

Sorry, seems like I forgot to respond back then.
I am using the latest v2.7-dev.
It is important that it is the latest as it includes my fix for this very issue with underscores and/or backslashes.
When I am back at my computer, I will also try out v3, but IIRC I had some issues with that back then.

I have just tested with txt2tags v3 (commit bc7f2c43f1a59ea96f37c77b63c4b44fe51e1b08) and it works perfectly fine on my system. I also have to admit that the output looks nicer than what v2 produces (e.g., HTML tags are not capitalized anymore).
Why did I use 2.7-dev then? Short answer: I don't remember. I think v3 did not work for me back then because I did not have an appropriate Python 3 version installed, but only Python 2.
Now that I have both, I would prefer txt2tags v3.

Also, if you need the corresponding error message with the second-to-newest build of txt2tags v2.7-dev, it looks like this (of course, it could also look slightly different, but it always has some $\backslash$ somewhere):

! Missing $ inserted.
<inserted text> 
                $
l.185     for \texttt{SmallExponent$\backslash$_t}
                                                   is \texttt{unsigned short...

The files released as 0.99850 work for me with txt2tags 2.6 (the latest stable 2.x version) as well as with txt2tags 3.4.

I suspect the issue described in #1662-23 to be an unrelated issue of that particular development version of txt2tags (and moreover it appears to be fixed in later development versions).

I think closing of this issue is long overdue.

AnnA can you check whether this issue can now be closed?
Ulrich reports that 0.99850 is OK with txt2tags-2.6; I seem to have version 3.4 (on Ubuntu 22.04), and have not noticed any problems. Currently don't have access to my older computers. Nico also seems to think that it is working. Did we use a workaround?

I am using txt2tags 3.9 and it works fine on my end as well. This issue was only related to txt2tags 2.7-dev (commits older than and excluding 1ad82c4), but it is fixed in the newest commit (1ad82c4).
So, as long as noone uses an outdated 2.7-dev version, everything should be fine - no workaround needed.

John Abbott wrote:

Did we use a workaround?

The workaround introduced in #1662#note-4 is indeed in effect in newer releases of CoCoALib.

Many versions of txt2tags, for example version 3.4, do not work on CoCoALib's files without such a workaround.

Of course it is even better if new releases of txt2tags don't need a workaround. I think this is the case thanks to Nico's work on txt2tags.