bug-groff
[Top][All Lists]
Advanced

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

[bug #59823] [ms] re-implement PN register


From: G. Branden Robinson
Subject: [bug #59823] [ms] re-implement PN register
Date: Mon, 4 Jan 2021 22:16:07 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #1, bug #59823 (project groff):

On further thought this might be really easy.  I may have already done the
"hard" part in the quoted commit.  The _only_ time the page number is parsed
is in the PT macro, which is now defined as follows.


.de PT
.\" To compare the page number to 1, we need it in decimal.
.ds pg*saved-page-number-format \\g%\"
.af % 0
.nr pg*page-number-in-decimal \\n%
.af % \\*[pg*saved-page-number-format]
.ie \\n[pg*page-number-in-decimal]=1 .if \\n[pg*P1] .tl \\*[pg*OH]
.el \{\
.       ie o .tl \\*[pg*OH]
.       el .tl \\*[pg*EH]
.\}
..


Access to % is serialized because the formatter is single-threaded (in
general, but more importantly with respect to input processing), so our
meddling with its format is invisible to any other operation that might access
%...including access through an alias.

So I am now thinking that this bug can indeed be resolved by throwing


.aln PN %


over the wall at an appropriate point in initialization and have done with it.
 Even if the user assigns a format to % or PN, they will never be able to
observe it while we have it temporarily set to decimal inside PT.

Lesk encourages the user to redefine PT if desired, so this point may be worth
noting in the documentation update portion of this bug's resolution.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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