Re: Periods at end of messages.

[John Darrington]

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
     problem.
     
     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 
sentence. 
  (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
message).

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
appropriate.

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.

J'



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