bugGNU roff - Bugs: bug #65654, [preconv] want a warning if code...

 
 

bug #65654: [preconv] want a warning if code '0xA0' is used in the input

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Sun 28 Apr 2024 06:58:35 PM UTC
   
 
Category:  Preprocessor preconv Severity:  1 - Wish
Item Group:  Warning/Suspicious behaviour Status:  Rejected
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 27 May 2024 07:49:14 PM UTC, comment #5: 

Correcting my earlier statement:

comment #2:

> 0xA0 appears to refer to the Latin-1 character NO-BREAK SPACE
> (Unicode U+00A0)--but there is no reason to run preconv if the
> file is in Latin-1 encoding,


My Latin-1 (ISO 8859-1) blinders were on: the byte 0xA0 is also the no-break space in encodings ISO 8859-2, ISO 8859-3, ISO 8859-4, etc., any of which would require preconv.

> Nonetheless, his point remains:


This makes the preceding (mis)statement mostly moot, but I wanted to correct the record.

Dave <barx>
Group Member
Mon 27 May 2024 07:34:15 PM UTC, comment #4: 

This proposal (with the warning upgraded to a fatal error) has been offered as one of the solutions to bug #65710.

Dave <barx>
Group Member
Wed 01 May 2024 10:40:16 PM UTC, comment #3: 

Dave has convinced me.

If the input code point U+00A0, which is valid as groff input, is not desired in a source file, write a Makefile/shell script to detect it.

Same as if you wanted to compose a document without using, say, an asterisk.  (Good luck with string interpolations, though.)

Closing as rejected.

comment #2:

> ...there is no reason for preconv to warn about this.  The same issue exists no matter what Unix tool processes input containing both characters.  Users may choose to avoid U+00A0 in their input files for this reason, or they may use other strategies to deal with it.  It is not preconv's job to police this usage.  Users who desire such warnings can write a simple preprocessor (using grep or sed, perhaps) to emit them.
>
> Once you start down the rabbit hole of "warn the user about characters that are hard to visually tell apart," where do you stop?  In the monospace fonts used in most terminals, you'd be hard-pressed to distinguish U+2012 FIGURE DASH from U+2013 EN DASH.  Unicode has a plethora of space-like and dash-like characters.  Should preconv warn about all of these?  That seems absurd.

G. Branden Robinson <gbranden>
Group administrator
Mon 29 Apr 2024 01:27:23 AM UTC, comment #2: 

Bjarni is talking about input, not output.  But the example is still slightly confusing, because 0xA0 appears to refer to the Latin-1 character NO-BREAK SPACE (Unicode U+00A0)--but there is no reason to run preconv if the file is in Latin-1 encoding, as groff can read this directly.

Nonetheless, his point remains: many common Unix tools display the characters U+0020 and U+00A0 indistinguishably.

But there is no reason for preconv to warn about this.  The same issue exists no matter what Unix tool processes input containing both characters.  Users may choose to avoid U+00A0 in their input files for this reason, or they may use other strategies to deal with it.  It is not preconv's job to police this usage.  Users who desire such warnings can write a simple preprocessor (using grep or sed, perhaps) to emit them.

Once you start down the rabbit hole of "warn the user about characters that are hard to visually tell apart," where do you stop?  In the monospace fonts used in most terminals, you'd be hard-pressed to distinguish U+2012 FIGURE DASH from U+2013 EN DASH.  Unicode has a plethora of space-like and dash-like characters.  Should preconv warn about all of these?  That seems absurd.

Dave <barx>
Group Member
Sun 28 Apr 2024 08:43:52 PM UTC, comment #1: 

Changing item group because this is a request for a new diagnostic message.

I don't understand the request, though.

`\~` is "displayed" as a normal space, too, if filling is off, or, depending on circumstances (especially on terminals) if it's not adjusted sufficiently to be distinguishable from a normal space.

Not sure why this is something worth warning about.

I will take this opportunity to note that if I ever implement my "AT&T-compatible troff preconv output" flag, we should convert U+00A0 to `\ ` instead.

G. Branden Robinson <gbranden>
Group administrator
Sun 28 Apr 2024 06:58:35 PM UTC, original submission:  

Subject: preconv.cpp: Issue a warning if code '0xA0' is used in
the input and thus changed to '\~'

File: "src/preproc/preconv/preconv.cpp"
Subroutine: unicode_entity(int u)

  The code '0xA0' is displayed as a normal space, and is thus
visually the same as it.

  So authors better use '\~' directly in their files.

Bjarni Ingi Gislason <bjarniig>

 

(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 barx (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by bjarniig (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-01 gbranden Severity3 - Normal 1 - Wish
    2024-05-01 gbranden Open/ClosedOpen Closed
    2024-05-01 gbranden StatusNeed Info Rejected
        Assigned toNone gbranden
        Summarypreconv.cpp: Issue a warning if code '0xA0' is used in the input and thus changed to '\~' [preconv] want a warning if code '0xA0' is used in the input
    2024-04-28 gbranden Item GroupLint Warning/Suspicious behaviour
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code