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

 
 

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

Submitted by:  Dave <barx>
Submitted on:  Wed 30 Jun 2021 06:05:59 PM UTC  
 
Category:  Utilities Severity:  2 - Minor
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  G. Branden Robinson <gbranden>
Open/Closed:  Closed Planned Release:  1.23.0

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

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