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

[Vincent Belaïche]

Answers inserted below...

Le 16/09/2015 11:09, Gavin Smith a écrit :
>> Since the nearly beginning of this whole tale of woe, I am thinking that
>> it would be better to solve the .fls case in texinfo.tex also rather
>> than just texi2dvi, my first idea was some fl<->_0 translation, and my
>> final idea is that non sorted index I should be named .I.idx, and sorted
>> index I should be named .I.ind.
>>
>> - This would follow the rule that filename extensions are used with
>>   parcimony and give some indication on the file format, and
>>
>> - This would make Texinfo closer to LaTeX to that respect.
>>
>> - This would not break the support of other languages (e.g. latex) in
>>   addition to Texinfo --- well I don't know if this support really is
>>   used by anybody, but if not it just makes the code more complex.
>>
>> Then tex2dvi would just deal the compatibility/tool interoperability
>> issues:
>
> 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.

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.


> 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


>> 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.

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

> 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.

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 ?).

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).

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.

VBR,
        Vincent

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com