Re: fprintf_ln() is slow

[Jeff King <peff@peff.net>]

On Thu, Jun 27, 2019 at 07:32:53PM +0700, Duy Nguyen wrote:

> > It's also not possible for translators to do this by mistake
> 
> This (accidentally dropping \n which sometimes is significant) is the
> part that I made me prefer *printf_ln(). I had been translating for
> years, as far back as 2003-ish, but I've stopped since the last few
> years so I'm no longer uptodate with gettext development. And my very
> old/outdated experience with gettext might make me think it's still
> the problem.
> 
> > without
> > being caught, because msgfmt will catch this (and other common issues):
> >
> >     po/de.po:23: 'msgid' and 'msgstr' entries do not both end with '\n'
> 
> Ok good. And with the downside of degraded performance, sure remove
> all the *printf_ln()

I don't have a strong opinion here. If you want to convert them all back
to embedded "\n", that's fine with me.

But I do suspect this same issue will come up in other places, too. For
instance, we already format into a buffer for error(), etc. Mostly for
atomic output as opposed to efficiency. And it's not just "\n", but
adding prefixes, etc.

It might be nice to have some generalized solution for writing to
stderr. And maybe it's even just using vreportf more widely. That also
caps the output length and munges unprintable characters, but that's
probably a good thing when we're going to stderr.

-Peff