[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Command line parsing of ls, tail and wc with genparse
From: |
Michael Geng |
Subject: |
Re: [PATCH] Command line parsing of ls, tail and wc with genparse |
Date: |
Sun, 7 Oct 2007 20:48:06 +0200 |
User-agent: |
Mutt/1.5.9i |
On Sun, Oct 07, 2007 at 02:48:43PM +0200, Bruno Haible wrote:
> 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.
I didn't know that it is desired to have the description for every command line
argument in a seperate string. I could add a new command line switch to
genparse
which automatically splits text this way.
> > > 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
I understand that you don't want to loose the possibility to add such translator
comments. Maybe I will add a new directive to the genparse file for it in one
of
the next versions.
Michael
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Bruno Haible, 2007/10/06
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Michael Geng, 2007/10/06
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Bruno Haible, 2007/10/06
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Michael Geng, 2007/10/07
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Jim Meyering, 2007/10/07
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Michael Geng, 2007/10/07
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Jim Meyering, 2007/10/08
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Bruno Haible, 2007/10/07
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse,
Michael Geng <=
Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Jim Meyering, 2007/10/06
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Michael Geng, 2007/10/07
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Michael Geng, 2007/10/09
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Jim Meyering, 2007/10/09
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Andreas Schwab, 2007/10/09
- Re: [PATCH] Command line parsing of ls, tail and wc with genparse, Jim Meyering, 2007/10/09