[PR translation/79638] "%ntid.y" confuses gcc.pot generation (was: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745))

Hi! On Thu, 16 Feb 2017 23:33:54 +, Joseph Myers wrote: > [...] So I > think one of the local fixes to avoid this particular case being > misdetected as a spec string should be preferred. Committed to trunk in r245623 (but I have not regenerated the gcc.pot

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

On Thu, 16 Feb 2017, Jakub Jelinek wrote: > > #define SPEC_MESSAGE(msg) msg > > > > "... %e" SPEC_MESSAGE ("Message") "} ..." > > > > and then only handling SPEC_MESSAGE specially in exgettext, rather than %e? > > We have over 90 of these, plus it would make the specs even harder to read.

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

On Thu, Feb 16, 2017 at 07:08:00PM +0300, Alexander Monakov wrote: > On Thu, 16 Feb 2017, Jakub Jelinek wrote: > > On Thu, Feb 16, 2017 at 01:56:15PM +0300, Alexander Monakov wrote: > > Are you sure you can't have them in *.c file (e.g. by setting some variable > > to a spec string or similar)? >

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

On Thu, 16 Feb 2017, Jakub Jelinek wrote: > On Thu, Feb 16, 2017 at 01:56:15PM +0300, Alexander Monakov wrote: > Are you sure you can't have them in *.c file (e.g. by setting some variable > to a spec string or similar)? > I think it is better to scan all those files. Hm, probably that idea was

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

On Thu, Feb 16, 2017 at 01:56:15PM +0300, Alexander Monakov wrote: > I'm unfamiliar with exgettext (and not objecting to the patch), but from a > quick git-grep it appears that specs strings where this %n/%e capturing needs > to take place only appear in gcc.c and a few .h files. And on the other

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

On Thu, 16 Feb 2017, Thomas Schwinge wrote: > On Mon, 9 Jan 2017 17:21:41 +0100, I wrote: > > On Thu, 29 Dec 2016 16:15:01 +0100, Jakub Jelinek wrote: > > > PR translation/78745 > > > * exgettext: Handle multi-line help texts in *.opt files. > > > > With this committed in

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

Hi! On Mon, 9 Jan 2017 17:21:41 +0100, I wrote: > On Thu, 29 Dec 2016 16:15:01 +0100, Jakub Jelinek wrote: > > PR translation/78745 > > * exgettext: Handle multi-line help texts in *.opt files. > > With this committed in r243981, I noticed the following new snippet in

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

Hi! On Thu, 29 Dec 2016 16:15:01 +0100, Jakub Jelinek wrote: > PR translation/78745 > * exgettext: Handle multi-line help texts in *.opt files. With this committed in r243981, I noticed the following new snippet in gcc/po/gcc.pot: +#: config/nvptx/nvptx.c:1132

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

On Thu, 29 Dec 2016, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, the option handling for multi-line help texts > concatenates those lines with spaces in between (essentially replaces > newlines with spaces), but exgettext extracts just the first line from the > multiline help text and

[PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

Hi! As mentioned in the PR, the option handling for multi-line help texts concatenates those lines with spaces in between (essentially replaces newlines with spaces), but exgettext extracts just the first line from the multiline help text and throws away the rest. With this patch, there are