bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vincent Belaïche
Subject: Re: [bug #43122] texi2dvi does not compile enough times to get toc
Date: Wed, 02 Sep 2015 23:46:43 +0200

My answers below...

Le 02/09/2015 11:18, Gavin Smith a écrit :
> On 2 September 2015 at 07:45, Vincent Belaïche
> <address@hidden> wrote:
>> Salut Gavin,
>>
>> My answers inserted below...
>>
>>> I see no need for a command-line flag.
>>>
>>
>> It allows you to test whether the \openout is still working. Otherwise
>> you may wind up with dead parts of code that are never (can't be ever)
>> tested. But anyway, I did not see any test bench for texi2dvi...
>
> The environment variable could still be used.
>>
>>
>>> "pushd" and "popd" are bash extensions, use cd instead.
>>>
>>
>> Done... MSYS sh did not bark at that.
>
> Did you see the attachment to my email?

Ooops... I had completely overlooked that. The latest patch which I have
sent was based on my previous patch as a starting point, not on your
email of 2015-09-01T19:40+02.

> I already made this change.
> Apologies if I could have made this clearer

No, it's my fault, I should have paid more attention to what was
attached to the email.

> - it would have saved you some effort.

No problem, sometimes it is more fruitful to follow parallel paths and
then to merge creatively.

For instance, by doing this revision I noted in that I had written a
2&>1 instead of 2>&1 in the make_openout_test fn. That was creating a
file named `1' instead of sending everything to /dev/null, which was the
intention.

> I'll have a look at your latest patch, anyway.

Thank you, and sorry for creating additional work by providing this
patch not starting from your work. I will also have a look to what you
have done.

> If I'd known you'd be willing do this work, I'd have waited to see
> what you did. Could you have a look at the latest version I emailed -
> it was supposed to be able to cope with an index called "fl".
>

As far as I understood the problem is that if you have a "fl" index then
texinfo will create a .fl file, and texindex will create a .fls file
from the .fl file, so this conflict with the .fls recorder file.

The simplest solution would be to document this case and tell the user
not to name any index `fl'.

One other idea would be that texinfo.tex would produce a `._0' file
instead of `.fl' file, ie rename `fl' to `_0' as far as filenaming is
concerned, while the `fl' name would remain in the .texi source. Because
Texinfo command forbid the `_' chacter `_0' cannot be use as an index
name, otherwise you would have an @_0index command for index entries,
which is not allowed. So `_0' cannot conflict with any index created by
the user.  Of course, to keep consistency, texinfo.tex would input the
`._0s' file produced by texindex every time a @printindex fl, and would
add an entry to the `._0' file at every @flindex command.

This way the current texi2dvi would work without any change. Well indeed
texi2dvi should probably do that:
- if the -recorder method is used, and
- if there is an fl index file produced, and
- if the texinfo.tex version is too old (meaning before the above described
  change)
then the processing is aborted and an error message is produced to
explain the cause and propose one of the following solution:
- update texinfo.tex
- rename index not to use fl
- compile with TEXI2DVI_USE_RECODER set to no, only for the lucky one
  whose TeX has the \openout traces, not for me :-(, but anyway I am not
  crazy enough to open a texinfo source containing an index named fl
  :-P.

>> Sorry, four spaces were the default with Emacs. I have added some Emacs
>> cookie at the end of the texi2dvi file to configure indent consistently
>> with the existing code. I hope that no one minds about that, otherwise
>> it is not a problem to do the same configuration via an sh-mode hook
>> function in my init file.
>>
>> I also noticed that you have one space between function names and `()',
>> I fixed that for new functions.
>
> Okay, thanks.
>
>>> Space after \openout in regexp. Check for single quote after filename.
>>> Remove $ anchor from end of regexp. Format for openout lines must
>>> differ between web2c and MikTeX.
>>
>> MikTeX does not have any openout lines, so I wrote the regexp w/o any
>> way for testing. Which regexp are you pointing at, that of the check
>> function ?
>
> Again, I was referring to the changes that I already had made.
>
>
>>> We'll also need a ChangeLog entry.
>>>
>>
>> Done, I also added something into the manual for all the environment
>> variables influencing texi2dvi (not only the new one).
>
> Thanks for the ChangeLog entry.
>>
>> Please note that I removed the trailing blanks in the ChangeLog.
>
> You shouldn't have bothered. They aren't causing any problems. I'm not
> going to commit this.
>

No problem, that should have anyway been in another change than this
one. As a rule of the thumb a commit should not tackle more than one
problem.

>>
>> For the manual, probably there should be some forward reference from
>> node `Format with texi2dvi' to node `Other Customization Variables', as
>> the latter is below texi2any.
>>
>>> Here's the current state. It would benefit from more testing and
>>> review. I'l have another look at it in the next couple of days.
>>
>> I definitely agree that more testing is needed. Some test bench with
>> something like
>>
>> rm -fr test.log
>> test1_options=-u no --tidy
>> test2_options=--tidy
>> test3_options=--tidy
>> for test in test1 test2 test3; do
>>   if texi2pdf ${${test}_options} $test.texi; then
>>     pdftotext $test.pdf
>>     if diff -q $test.txt ref/$test.txt; then
>>       echo "Failed diff to ref: $test" >> test.log;
>>     fi
>>   else
>>       echo "Failed compilation: $test" >> test.log;
>>   fi
>> done
>
> Would you, or anybody else, like to get this working? I agree a test
> bench would be very helpful.

I am afraid I cannot take this on right now, I am too busy, maybe this
task should be registered in the savannah tracker.

  Vincent.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]