[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Periods at end of messages.

From: John Darrington
Subject: Re: Periods at end of messages.
Date: Sun, 12 May 2019 11:31:41 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Sat, May 11, 2019 at 08:47:36AM -0700, Ben Pfaff wrote:
     On Sat, May 11, 2019 at 09:49:47AM +0200, John Darrington wrote:
     > Some of our message strings end with a '.'  Whilst others do not.
     > This is inconsistent.
     > The GNU Coding standards say that messages from interactive programs
     > should not end in a period [1] .
     > So I'm considering this patch:
     > diff --git a/src/libpspp/message.c b/src/libpspp/message.c
     > index de3dab8d..0a57e217 100644
     > --- a/src/libpspp/message.c
     > +++ b/src/libpspp/message.c
     > @@ -347,6 +347,16 @@ process_msg (struct msg *m)
     >  void
     >  msg_emit (struct msg *m)
     >  {
     > +  if (m->text [strlen (m->text) - 1] == '.')
     > +    {
     > +      if (0 == strcmp ("C", setlocale (LC_MESSAGES, NULL)))
     > +       {
     > +         fprintf (stderr, "Message \"%s\" should not end in a period.",
     > +                  m->text);
     > +         abort ();
     > +       }
     > +    }
     > +
     > Lots of source files and tests would need to be fixed too.  Thoughts?
     I support consistency and compliance with the GNU coding standards here.
     Please do not commit this particular implementation: it means that a
     harmless stylistic issue crashes the program, irritates the user, and
     spawns bug reports.

I meant to include a condition which checked that the --testing flag was
passed, but I forgot.
     It will also have "false positives" where there's some %s at the end of
     a message whose expansion ends in a period, causing spurious crashes.
     Since PSPP variable names can end in a period (even though that's a bad
     idea), and because PSPP syntax lines definitely do, that might be a real
     I'd suggest, instead, that we can find most of these messages with
     "grep" or "git grep", e.g.: git grep '\.")'

I've done some experiments like that, and using msggrep too.  It's hard
to find a filter which is useful.
     The standards also say that error messages that include a file name or
     program name should not begin with a capital letter.  PSPP violates that
     a lot too.

I think you're refering to this text:

  "The string message should not begin with a capital letter when it follows a 
  program name and/or file name, because that isn't the beginning of a 
  (The sentence conceptually starts at the beginning of the line.)  Also, it 
  should not end with a period."

This refers to messages like: "PSPP: unknown option --xyzzy" 
or "foo.sps: the command COX is not implemented".  It doesn't mean that
the mere mention of a filename or program name in the message demands it
start with a lower case.

Anyway reading the GCS again.  This entire section is headed "Formatting
Error Messages."  Not all our strings are error messages (and it would
be silly if we were to remove all periods from the end of every

This lead me to discover that we (well actually I) have used msg (SE,
_("...")) in a lot of cases where lex_error (_("...")) would have been

I guess the gist of my message was that we need some kind of systematic
method to help catch inconsistencies in the formatting and use of of
error/warning/info messages.


Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

reply via email to

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