bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #57416] [PATCH] repair .AT and .UC in the groff_man(7) macros


From: G. Branden Robinson
Subject: [bug #57416] [PATCH] repair .AT and .UC in the groff_man(7) macros
Date: Sun, 5 Feb 2023 02:11:38 -0500 (EST)

Follow-up Comment #7, bug #57416 (project groff):


commit a628605e2b26106a6e1e5afbf8cc390283099fa8
Author:     Ingo Schwarze <schwarze@openbsd.org>
AuthorDate: Thu Jan 16 13:59:48 2020 +0100
Commit:     Ingo Schwarze <schwarze@openbsd.org>
CommitDate: Thu Jan 16 14:19:17 2020 +0100

    Repair .AT and .UC in the groff_man(7) macros.
    
    * tmac/an-old.tmac:
    Setting user-defined strings in a macro that will later be called
    indirectly from page location traps is excessively complicated.
    Besides, the implementation doesn't work: when the trap is finally
    sprung, the defaults from the an-init macro clobber what the author
    specified with .AT or .UC.
    Instead, all that is needed is setting the strings for the header
    before triggering the page break, such that they appear right
    away, while setting the strings for the footer after the page
    break, such that they don't appear on the previous page.
    
    This bug was found by Jonathan Gray <jsg@openbsd.org>
    while he looked at 4.xBSD manual pages.
    
    Thanks to gbranden@ for finding a bug in first version of my patch
    and for agreeing with the idea, see: https://savannah.gnu.org/bugs/?57416


I'm not sure the "patch" annotation should be retained, but I'm leaving it for
now.  I don't think any official semantics are defined anywhere, but the
denotation I've drifted toward over the past five years are that a ticket get
the "[PATCH]" annotation initially when a patch is attached to the ticket,
either at creation or later, from someone who doesn't have (or elects not to
use their) commit rights to the groff Git repository.  The annotation is
retained if the patch is accepted by the developers, and removed if it is
not.

If people agree, I guess the above should be written down somewhere more
discoverable.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57416>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]