Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Gavin Smith]

On 18 September 2015 at 08:09, Vincent Belaïche
<address@hidden> wrote:
> Answers inserted below...
>
> Le 16/09/2015 11:09, Gavin Smith a écrit :
>> I don't think we should change the file extensions any more than in
>> necessary (.fl and .fls possibly).
>
> That was my previous idea (.fl <-> ._0 renaming).  But I don't like it so
> much because I think that having more filename extensions than types of
> file format is per se an issue. Also I hate the idea that we have a
> special case just for the name fl, all index files should be handled
> equally.
>
> Having more filenames extensions than actual file types is indeed the
> root cause of this .fls problem, and we are just healing the symptom,
> not the root cause, so sooner or later there will be a recurrence.
>
>> Users are familiar with them and files with unusual names appearing
>> would be distracting.
>
> It is already the case that there are unusual names appearing. If I do
>
> @defindex doodoodimdoo
>
> Then I will have a file with extension .doodoodimdoo, which is very
> unusual. So let us solve this issue, and get rid of these unusual
> distracting names by having names with standard extensions .idx and
> .ind.

Index names are usually only two-letters long. I don't think it's a
requirement, though.

>
> Furthermore, changing filenames to unusual ones is exactly what is done
> by the current fix, the .flz extension is unusual and users may be
> distracted by it, if for some reason they are seeking the recorder file,
> knowing from the manual or from verbosing that it is generated.

There may be some way to only rename the recorder file if there is
also an fl index.

>> Also they know what files to delete in order to delete the index
>> files.
>>
>
> It is easier to know what files to delete when you have only two
> extensions .idx and .ind, than when you have six potential extensions .ky
> fn cp vr tp pg

Also good for debugging sometimes, you can look at the cp file to see
what's in the concept index.

It seems like change for the sake of change to me, for very little
benefit. That can only cause distraction and confusion. Many such
changes add up over time.

>>> The above would be the ideal (meaning less risky, more futureproof) fix
>>> in my opinion, but I can understand that there is so much tool
>>> interoperability issues that one is hesitant to go this way.
>>
>> Yes, interoperability is a big problem. texinfo.tex, texindex,
>> texi2dvi. If you say each version is new or old, you have 8
>> possibilities, and you have 6 ways of ordering them in order of age.
>>
>
> It could not be so big, because we should make texi2dvi/texindex
> backward compatible with the older extensions and make the update in
> texinfo.tex one or two years later than for texi2dvi/texindx, assuming
> that all user would have an uptodate texi2dvi/texindex at that time.
>
> So, assuming that the user would have an older texinfo.tex the problem
> would arise only in the case when the texinfo file has a user index
> named fl --- and even in that case, at least for MikTeX the compilation
> would run fine, as you will see below.

It wouldn't be so bad to break or change things for the fl index only,
as that is a reasonably rare case. Maybe by renaming the extension to
_0 or something, as you suggest.

> Based on all referenced manuals publicly available, do we have any
> statistics on how often this fl user index name happens.

No, the only evidence we have for it is that Karl said that he's used
it. But many small breakages add up to big breakage over time.

>> If it's possible to make the parts interoperate automatically then
>> that would be better than telling people to upgrade.
>
> I agree, but on the other hand I must now withdraw what I had previously
> written: the current fix in fact does not work as expected for MikTeX. I
> had thought that everything was fine because the compilation went
> through without any halt due to an error. However, having a look at the
> recorder log (.flz file) I realized that the sorted indexes are input
> from the build directory, not from the bak directory.
>
> I have the following output when I verbose:
>
> /local/bin/texi2dvi: 
> TEXINPUTS='/c/Programmes/installation/texinfo-install/trunk/util/dummy.t2d/pdf/bak:/c/Programmes/installation/texinfo-install/trunk/util:/c/Programmes/installation/texinfo-install/trunk/util/.:../bak'
>
> But in the recorder I have
>
> INPUT 
> c:/Programmes/installation/texinfo-install/trunk/util/dummy.t2d/pdf/build/dummy.fls
> INPUT 
> c:/Programmes/installation/texinfo-install/trunk/util/dummy.t2d/pdf/build/dummy.cps
>
>
> So, it seems that MikTeX is running with the build directory as current
> directory, and that although the build directory is not in TEXINPUTS it
> is implicitely searched before pathes in the TEXINPUTS envvar.

This looks like a MikTeX bug.

For clarification, this is a problem because MikTeX will have
dummy.fls open for both writing as a recorder file and reading as an
index file. (Mentioning because I forgot this, briefly.)

Where there is a will, there is a way. This could be fixed by making
all input files be read from a different directory from the current
directory.

What a confusing mess this all is though.

> So there is no way to give higher precedence to bak than to
> build. Things are working properly because MikTeX (maybe with the help
> of MSW filesystem) does not cause any write before read of the .fls
> file. However I do not know whether this will happen always, or if it
> depends on the .fls size or of MikTeX/OS version, I am using MikTeX 2.9
> on MSW 7 (what about 2.8 on XP ?).

Do we have confirmed incorrect behaviour on any combination of TeX
distribution and operating system?


> My conclusion is that the current solution is not very satisfactory,
> because it relies on the TeX engines implementing TEXINPUTS
> ``properly'', which is not guaranteed (I have even read that MikTeX
> version 2.4 and before was not using it at all).

So we can't rely on \openout appearing in the log files, we can't rely
on TEXINPUTS working. It makes we wonder if there's any hope of
supporting multiple TeX engines properly. It makes it complicated to
run lots of tests to see what features they have. We have to test for
-recorder because that isn't everywhere. Unfortunately we seem to want
to use unofficial TeX features, not put in by the original author, and
they've been implemented differently. Karl pointed out to me that the
\openout lines weren't in Donald Knuth's source, which is why they
differ. Hopefully the format of the *.fls recorder files won't differ
as well.

>
> I am not even sure that this is a bug of MikTeX, rather a design choice:
> there will always be people to think that not searching the current
> directory first because of some envvar setting will cause more confusion
> for non experienced users. Doing otherwise, as the current fix does,
> may bring even more confusion than changing the filename extension to
> LaTeX-ish one. Please do not forget that even Texinfo fans probably
> write more often LaTeX document than Texinfo documents.

It's a possibility to change the file extensions for consistency with
LaTeX, but I'm not sure.