Re: gmail

[Slightly off-topic, but anyway.] Mike Fulton wrote: > > A: Because it messes up the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > > is there a way to get gmail to change it's default 😁 In gmail as a web application, you can't avoid top-posting without

gnulib-tool.py consider automake_subdir=false support

I am doing some quick and dirty things currently for compiling a slew of (mostly) gnu software of Windows. I hope to have some semi-quality patches to submit soon enough. I have been very grateful for gnulib-tool.py as it results in some massive bootstrap speed improvements (over 10x) on Windows

Re: add __MVS__ to list of systems that should default to UTF-8 in localcharset.c

On Thu, Jun 1, 2023 at 8:23 AM Bruno Haible wrote: > Hi Mike, > > > It looks right but I do see 3 warnings: > > > > :troff: man7/groff_char.7:1051: warning: can't find special character > 'bs' > > troff: man7/groff_char.7:1192: warning: can't find special character > > 'radicalex' > > troff: man7

Re: request for update to z/OS progname

Hi On Thu, Jun 1, 2023 at 7:20 AM Bruno Haible wrote: > Mike Fulton wrote: > > Yes - good point - this would not work if it was built in 31-bit > addressing > > mode, non-XPLINK. 64-bit is always XPLINK. That would be a good addition. > > OK, thanks for the confirmation. I pushed this change: >

Re: add __MVS__ to list of systems that should default to UTF-8 in localcharset.c

Hi Mike, > It looks right but I do see 3 warnings: > > :troff: man7/groff_char.7:1051: warning: can't find special character 'bs' > troff: man7/groff_char.7:1192: warning: can't find special character > 'radicalex' > troff: man7/groff_char.7:1195: warning: can't find special character > 'sqrtex'

Re: request for update to z/OS progname

Mike Fulton wrote: > Yes - good point - this would not work if it was built in 31-bit addressing > mode, non-XPLINK. 64-bit is always XPLINK. That would be a good addition. OK, thanks for the confirmation. I pushed this change: 2023-06-01 Bruno Haible getprogname: Add support for ASC

Re: [PATCH] gnulib-tool.py (pygnulib) minor print warn crash fix

Thanks, I pushed your patch, with this ChangeLog entry: 2023-06-01 Mitch Capper gnulib-tool.py: Fix a format string mistake. * pygnulib/GLImport.py (GLImport.execute): Fix a typo in a format string. Copyright-paperwork-exempt: Yes

Re: Copyright-paperwork-exempt

Paul Eggert wrote: > On 2023-05-31 04:57, Bruno Haible wrote: > > > But I think it would be good to write > >Copyright-paperwork-exempt: yes > > (like everyone else does), not > >Copyright-paperwork-exempt: true > > Yes, that was my intent; I merely forgot whether it was "yes" or "true".

Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

On 01/06/2023 13:10, Bruno Haible wrote: Pádraig Brady wrote: Was there a reason to prefer curly braces there, rather than the more conventional parentheses? '$(error_fns) \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \ I had a slight preference for the curly braces since it was used

Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

Pádraig Brady wrote: > > Was there a reason to prefer curly braces there, rather than the more > > conventional parentheses? > > > > '$(error_fns) \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \ > > I had a slight preference for the curly braces since it was used in a shell > pipeline >

Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

On 31/05/2023 18:46, Jim Meyering wrote: On Wed, May 31, 2023 at 9:12 AM Pádraig Brady wrote: - 'error \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \ + '${error_fns} \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \ Thanks! Was there a reason to prefer curly braces there, rather th