bugGNU roff - Bugs: bug #55124, doc/groff.texi: text about...


bug #55124: doc/groff.texi: text about negative .pl values needs clarification

Submitter:  Dave <barx>
Submitted:  Wed 28 Nov 2018 03:13:30 PM UTC
Category:  Core 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

Fri 23 Jun 2023 12:06:58 PM UTC, comment #4: 

commit 6dd07b45478a5cdf8a9fe0c2110928af2c516e24
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jun 22 13:38:38 2023 -0500

    ChangeLog: Add retrospective bug closer.

    Always good to find you've fixed a bug by accident.

    Fixes <https://savannah.gnu.org/bugs/?62973>.  Thanks to Dave Kemper for
    the original report and noting the fix.

    ANNOUNCE: Update bug counts.

G. Branden Robinson <gbranden>
Group administrator
Thu 22 Jun 2023 04:39:54 PM UTC, comment #3: 

Commit 9be6acf9 fixed this, rewriting the offending sentence into: "A negative @var{length} is valid, but an uncommon application:@: it prevents page location traps from being sprung,@footnote{@xref{Traps}.}  and each output line is placed on a new page."  This addresses both issues I identified with the original wording.

Marking as Fixed, but not closing, as Branden will want to update the fixed-bug counts in ANNOUNCE, so I'll give him the satisfaction of closing the bug once that's done.

Dave <barx>
Group Member
Wed 10 Nov 2021 12:10:11 AM UTC, comment #2: 

The idea of changing .pl's behavior, as floated in comment #1, has now been spun off into bug #61453.  The present bug is now concerned only with disambiguating the documentation to better explain the current behavior.  That is, disregard comment #1 and read only comment #0.

Dave <barx>
Group Member
Mon 17 Dec 2018 03:49:07 AM UTC, comment #1: 

Regarding point (2): it's also worth considering changing .pl's behavior to the more useful option.  It can't be too detrimental to back compatibility to change behavior that the documentation already admits is rather useless.

Further, the current way to get a single long page (documented under the .em macro) is a bit of a crude hack that prevents footnotes (or other diverted text placed relative to the page bottom) from being output.  Making groff interpret a negative .pl value as an infinitely long page could provide a simpler and less error-prone way to achieve this result.

Dave <barx>
Group Member
Wed 28 Nov 2018 03:13:30 PM UTC, original submission:  

Part of the .pl section of the info manual states:

Negative @code{pl} values are possible also, but not very useful: No trap is sprung, and each line is output on a single page

This contains a couple of ambiguities:

(1) "No trap is sprung": This wording makes it sound like this is referring to a specific trap; otherwise, it would say "no traps are sprung," or "no traps of type (x) are sprung."  But no specific trap is mentioned in this section.  The paragraph before refers to traps in a general sense for setting top and bottom margins; these are usually page-location traps, which indeed are not sprung with negative .pl values.  But input line traps, for example, are sprung.  I haven't comprehensively tested which types of traps are sprung and which aren't, so I don't yet have a suggested replacement wording.

(2) "each line is output on a single page": This could be read two different ways: all output is on a single, unending page; or each line of output starts a new page.  The second is what actually happens (which is an odd choice, as the first would be useful for TTY output, while it's hard to imagine a real-world use for the second--a fact the documentation even acknowledges by calling the behavior "not very useful"), so the wording should say this more unambiguously.

Dave <barx>
Group Member


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

Attach Files:

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
    2023-06-23 gbranden Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2023-06-22 barx Severity3 - Normal 2 - Minor
        StatusNone Fixed
        Assigned toNone gbranden

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code