bugGNU roff - Bugs: bug #60862, grog(1) documents limitation with...

 
 

bug #60862: grog(1) documents limitation with invalid example

Submitter:  Dave <barx>
Submitted:  Wed 30 Jun 2021 06:05:59 PM UTC
   
 
Category:  Utilities Severity:  2 - Minor
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 01 Jul 2021 05:07:43 PM UTC, comment #2: 


commit 3ed8e933f494c18755edf05ee887f1c032289aec
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jul 1 21:59:06 2021 +1000

    [grog]: Simplify parsing.

    * src/utils/grog/grog.pl: Simplify parsing.  Dave Kemper pointed out
      that preprocessors like pic(1) use pretty unsophisticated *roff
      parsing to determine where to perform their textual replacements.  My
      enhancements to support input line continuation and cope with brace
      escapes were thus overengineered.  Remove them.

      - Drop scalars `is_continued_line` and `logical_line`.

      (do_line): Stop performing logical line concatenation and detecting
      input line continuation.  Perform operations on `line` instead of
      `logical_line`.  Stop removing brace escapes.

    * src/utils/grog/grog.1.man (Limitations): Update discussion.

    Fixes <https://savannah.gnu.org/bugs/?60862>.  Thanks, Dave!


G. Branden Robinson <gbranden>
Group administrator
Thu 01 Jul 2021 11:20:27 AM UTC, comment #1: 

Yup, that's a good point.  I had blinders on when I wrote that.

Hmm.  So soelim(1) is just not a document that benefits from groff -p, and its ".mso pic.tmac" request was not (just) a redundancy to work around man(1) programs that would not anticipate the need to run any man page through pic, but essential to getting the page to render correctly on typesetter devices.

This has me rethinking now whether I even need the stuff I added to grog(1) to handle input line continuation and strip brace escapes.  It's not a large code savings if I get rid of them, but it was this very scenario that motivated me to add them in the first place.

G. Branden Robinson <gbranden>
Group administrator
Wed 30 Jun 2021 06:05:59 PM UTC, original submission:  

src/utils/grog/grog.1.man states:

   grog does not parse roff control structures (the "if", "ie", and "el" requests) nor groff's "while".  Thus the input
         .if t .PS
         .if t .PE
  will not, for example, cause grog to infer use of the pic(1) preprocessor.

This may be valid to point out in general, but the specific example is not: pic will also not recognize those lines as begin and end markers.  pic requires that the .PS and .PE be at the start of the line, without so much as a space between the dot and the macro name.

Thus, pic will not preprocess lines set off as in the example above, so grog is actually correct to not output the -p option based on them.

Dave <barx>
Group Member

 

(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 gbranden (Posted a comment)
  • -email is unavailable- added by barx (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
    2021-07-01 gbranden StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2021-07-01 gbranden StatusNone Confirmed
        Assigned toNone gbranden
        Planned ReleaseNone 1.23.0

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code