bug-coreutils
[Top][All Lists]
Advanced

[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




reply via email to

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