bugGNU roff - Bugs: bug #52374, migrate diagnostic messages away...

 
 

bug #52374: migrate diagnostic messages away from `quotes like this'

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Thu 09 Nov 2017 12:01:26 PM UTC
   
 
Category:  General Severity:  3 - Normal
Item Group:  Feature change Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.22.4
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 18 Jun 2018 07:43:13 AM UTC, comment #4: 

Several commits fixed this, the last being:


commit 1294c8d2272e1c43b1b683e287deb1749865e642
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat Nov 18 17:55:26 2017 -0500

    tmac: Move macro diagnostics away from `quotes'.


G. Branden Robinson <gbranden>
Group administrator
Thu 09 Nov 2017 08:07:52 PM UTC, comment #3: 


  I second that (with a comment):

1) it is in my list "It is time to modernize "groff""
[lists.gnu.org/archive/html/groff/2017-08/msg00054]

2) See the "GNU Coding Standards", paragraph 5.10 Quote Characters.

  Comment (UTF-8):

  I find that people too often _type_ (or copy) multibyte quotation marks
where the ASCII ones are totally sufficient.

  This caught my attention in "ChangeLogs" for Debian packages, where also
other multibyte punctuations were used.
As ASCII transliterations were used hitherto and still can be used.
Multibyte punctuations are not backward portable, but as people got the new
tool (toy) they forgot all about what they had used prior to that.

  Also the did not understand the demand to use UTF-8 encoding for
changelogs.
It is only needed to encode non-English (non-ASCII) letters.

  For examples of unnecessary (and not backwards portable characters) in the
Debian ChangeLogs see the last part of this writing.

  So please do not use multibyte characters for punctuations in patches
or changelogs.
The ASCII-ones are sufficient (and faster to type).

N.B.  I use an 8-bit locale as I do not need anything more.
And I see more that way!

###

punct.sed (with bytes both in hexadecimal and UTF-8 representation):

#!/bin/sed -f
s/\xE2\x80\x98/'/g  # u2018, left single quotation mark
s/\xE2\x80\x99/'/g  # u2019, right single quotation mark
#s/â^À^Ù/'/g  # u2019, right single quotation mark
s/\xE2\x80\x9C/"/g  # u201C, left double quotation mark
#s/â^À^Ü/"/g  # u201C, left double quotation mark
s/\xE2\x80\x9D/"/g  # u201C, left double quotation mark
#s/â^À^Ý/"/g  # u201D, right double quotation mark
s/\xE2\x80\xA2/*/g   # u2022, bullet, "iconv" uses 'o'
#s/â^À¢/*/g   # u2022, bullet, "iconv" uses 'o'
s/\xE2\x94\x81/-/g  # u2501, box drawings heavy horizontal
#s/â^Ô^Á/-/g  # u2501, box drawings heavy horizontal
s/\xC2\xA0/ /g     # u00A0, no-break space
#s/ / /g     # u00A0, no-break space
s/\xE2\x80\x93/--/g # u2013, en-dash (as in TeX)
#s/â^À^Ó/--/g # u2013, en-dash (as in TeX)
s/\xE2\x80\x94/---/g # u2014, em-dash (as in TeX)
#s/â^À^Ô/---/g # u2014, em-dash (as in TeX)
s/\xE2\x96\xA1/*/g   # u25A1, square
#s/â^Ö¡/*/g   # u25A1, square
s/\xE2\x8B\xAF/.../g # u22EF, midline horizontal ellipsis (mathematical operator) (wrong character)
#s/â^˯/.../g # u22EF, midline horizontal ellipsis (mathematical operator) (wrong character)
s/\xE2\x80\xA6/.../g # u2026, horizontal ellipsis
#s/â^À¦/.../g # u2026, horizontal ellipsis
s/\xE2\x98\x86/*/g  # u2606, white star
#s/â^Ø^Æ/*/g  # u2606, white star
s/\xE2\x86\x92/->/g  # u2192, rightwards arrow
#s/â^Æ^Ò/->/g # u2192, rightwards arrow


Bjarni Ingi Gislason <bjarniig>
Thu 09 Nov 2017 03:05:11 PM UTC, comment #2: 

Thanks, Werner!

In a fit of optimism, I am already under way.

I haven't managed to break the build yet, and I've hit every subdirectory of src except preproc.

I sure do wish we had a test suite that exercised all the error and warning paths in src/roff/troff/input.cpp, though.

G. Branden Robinson <gbranden>
Group administrator
Thu 09 Nov 2017 02:44:46 PM UTC, comment #1: 

Sounds sensible, so please proceed.

Werner LEMBERG <wl>
Group administrator
Thu 09 Nov 2017 12:01:26 PM UTC, original submission:  

Recently (and at long last) GNU tools have begun migrating away from using grave accents and apostrophes as if they were mirror-symmetrical quotation marks.

For example, GNU diff has stayed within ASCII and simple uses "straight" single quotes (apostrophes) to mark literals within diagnostics:


diff: missing operand after 'nonexistent'
diff: Try 'diff --help' for more information.


GCC has gone even further and uses actual Unicode quotation marks.


src/devices/grolbp/lbp.cpp: In member function ‘void lbp_printer::setfillmode(int)’:
src/devices/grolbp/lbp.cpp:390:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
     else
     ^~~~
src/devices/grolbp/lbp.cpp:393:7: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
       fill_mode = mode;
       ^~~~~~~~~


As groff does not appear to be internationalized, and local detection and message catalogs would be necessary to quote in the GCC style, I propose to follow GNU diff's example.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-05 gbranden CategoryNone General
        Summarysrc: Migrate diagnostic messages away from `quotes like this' migrate diagnostic messages away from `quotes like this'
    2018-06-18 gbranden Planned ReleaseNone 1.22.4
    2018-06-18 gbranden Open/ClosedOpen Closed
    2017-11-09 gbranden StatusIn Progress Fixed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code