Re: pg_dump.options.diff

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: January 02, 2003 1:58 PM

> "Serguei Mokhov" <mokhov(at)cs(dot)concordia(dot)ca> writes:
> > Looks good to me, but there is still a little inconvenience
> > of multiline option descriptions, and the above won't handle
> > it nicely.
>
> True, a multiline description would have to look like
>
> xo(_("-f, --file=FILENAME "),
> _("-f FILENAME "),
> _("output file name\n"
> " more description"));
>
> Which is not great, but it doesn't seem completely unworkable either.
> And the translator can still adjust the column spacing without any
> code changes.

Well, it's better than before and solves *my* (and other translators')
problem.

Now, this:

#if defined(HAVE_GETOPT_LONG)
#define xo(long,short,desc) printf("%s %s\n", long, desc)
#else
#define xo(long,short,desc) printf("%s %s\n", short, desc)
#endif

seems relatively generic, so it could be used by more than one tool.

I searched for 'util' the source tree to see a more or less
logical place to put it. I got a whole bunch of .*util.* files,
but none of them seems appropriate enough because they all specific
to some other tool or smth else. Is pushing it up to c.h an option,
or it'll become too polluted? Where should I place it?

> > may be a whole generic option-formatting routine
> > should be created; one for all the tools? ;-)
> > Similar to explain_option() of Manfred,
> > which will handle the mulitline, padding, and other stuff?
> > (am being half serious here, but it could be an "option")
>
> The trouble I see there is that the layout --- in particular the column
> width --- would be embedded in such a routine and not alterable by
> simply replacing message texts.

True, but what would be wrong by having an argument for the column width?

-s