Re: Request for feedback on texi2any customization file

[Jonas Hahnfeld]

On Wed, 2023-08-30 at 00:08 +0100, Gavin Smith wrote:
> On Tue, Aug 29, 2023 at 10:58:21AM +0200, Jonas Hahnfeld wrote:
> > Is it possible to make texi2any fail if there is a syntax error or
> > other severe problems in an initialization file? Right now, the 'eval'
> > call only seems to emit a warning and just carry on without our
> > customization code which was a bit infuriating during development...
> 
> This at least should be easy to fix.  It looks like it would a change
> like
> 
> diff --git a/tp/Texinfo/Config.pm b/tp/Texinfo/Config.pm
> index 47082541fa..64cb69c393 100644
> --- a/tp/Texinfo/Config.pm
> +++ b/tp/Texinfo/Config.pm
> @@ -116,7 +116,7 @@ sub _GNUT_document_warn($) {
>    return if (texinfo_get_conf('NO_WARN'));
>    my $text = shift;
>    chomp ($text);
> -  warn(_GNUT_encode_message(
> +  die(_GNUT_encode_message(
>          sprintf(__p("program name: warning: warning_message",
>                     "%s: warning: %s"), $real_command_name, $text)."\n"));
>  }
> 
> Of course, we'd have to decide if this change should be made
> unconditionally or if it should be configured somehow.

Not quite, I'm fine with warnings not resulting in errors (even though
a -Werror like flag would be a nice addition!)

> However, I don't fully understand what the problem is with carrying on.
> Could you not test the code with "-c TEXINFO_OUTPUT_FORMAT=parse " just
> to see if any messages are printed with the customization code, without
> doing the conversion to HTML?

Much of the more elaborate customization code will only run during
conversion to HTML, so this *MUST* be part of the testing process. The
problem I've been running into a lot (not being a versed Perl dev) are
syntax errors in the customization file. To give the most simple
example to reproduce, create a file error.init with the content "syntax
error;" (ok, I'm also not that bad in writing Perl, but a forgotten
semicolon here and there was certainly part of the story...)

 $ texi2any --html --init-file error.init --error-limit 0 short_sample.texi
texi2any: warning: error loading ./error.init: Can't locate object method 
"syntax" via package "error" (perhaps you forgot to load "error"?) at 
./error.init line 1.
 $ echo $?
0

Using the builtin error mechanism of returning a non-true value only
results in a warning; put "return 0;" into a file return0.init:
 $ texi2any --html --init-file return0.init --error-limit 0 short_sample.texi 
texi2any: warning: error loading ./return0.init: ./return0.init did not return 
a true value at /usr/share/texinfo/Texinfo/Config.pm line 130.
 $ echo $?
0


> > For lilypond_label_target_name, we need to deal with three different
> > function signatures if we want to support a range of Texinfo versions:
> > four arguments in current master / post-7.0; three arguments in Texinfo
> > 7.0; two arguments before Texinfo 7.0. Can we expect this signature
> > (and others) to be stable after the release of Texinfo 7.1? (originally
> > I thought Texinfo 7.0 already marked a stable API, but here we are...)
> 
> Hopefully Patrice will answer this.
> 
> I looked at the definition of lilypond_label_target_name in the patch
> you linked.  One thing that confuses me is the function signature:
> 
>     sub lilypond_label_target_name($$$$) {
> 
> If the function only receives three arguments, then this is incorrect.
> It's likely the signature isn't being checked.  No signature would be
> better:
> 
>     sub lilypond_label_target_name {
> 
> Or possibly mark the third and fourth arguments as optional:
> 
>     sub lilypond_label_target_name($$;$$) {

Yes, valid points... For explanation, this is one of the first
customization functions I wrote while looking at texi2any_api.texi in
master, not being aware that the signature changed (multiple times)
over the range of Texinfo versions that should be supported (currently
Texinfo 6.7 and any later version).

Jonas

signature.asc
Description: This is a digitally signed message part