Re: [PATCH] Command line parsing of ls, tail and wc with genparse

[Bruno Haible]

Michael Geng wrote:
> > 1) The gettext documentation [1] recommends to not make the _() arguments
> > unnecessarily large.
> 
> The text is partitioned exactly as it is in the existing code of tail.c (I'm 
> looking at a cvs archive copy from sept 9). This is from tail.c:
> 
>       fputs (_("\
>       --files0-from=F    read input from the files specified by\n\
>                            NUL-terminated names in file F\n\
>   -L, --max-line-length  print the length of the longest line\n\
>   -w, --words            print the word counts\n\
> "), stdout);

This is too large already now in tail.c. I haven't told Jim about it in
the past because there are dozens of program maintainers who would have
to change hundreds of usage messages manually.

The difference is that you are writing a tool, and your tool already knows
where the description of each option starts and ends.

> Genparse could easily generate the above code if you added more __NEW_PRINT__
> directives to the genparse file like this:
> 
> NONE / files0-from=F  string  "read input from the files specified by"
>                               "  NUL-terminated names in file F__NEW_PRINT__"
> L / max-line-length   flag    "print the length of the longest 
> line__NEW_PRINT__"
> w / words             flag    "print the word counts__NEW_PRINT__"

Why should the maintainer have to write __NEW_PRINT__ everywhere here?
It's clear from the input where the description of each option ends. Your
tool can add __NEW_PRINT__ implicitly there.

> > 2) What about translator comments? How can a maintainer provide
> > additional information for the translators? Does this work?
>
> When I grep for "TRANSLATORS" in the coreutils src/ directory I can find
> only 3 hits however ...
> Do you see more examples of translator comments in the coreutils code for
> which you think genparse should handle them?

This is not a strong argument.

Bruno