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 21:37:01 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

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

                 Summary: [ms] re-implement PN register
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Tue 05 Jan 2021 02:37:00 AM UTC
                Category: Macro - ms
                Severity: 4 - Important
              Item Group: Incorrect behaviour
                  Status: Need Info
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

In commit 08291b401786f57ffb8c8c3551455167bcfb4d31 last year, I eliminated the
PN register.


commit 08291b401786f57ffb8c8c3551455167bcfb4d31
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Oct 25 20:57:39 2020 +1100

    tmac/s.tmac: Fix page number in table of contents.
    
    Fix ms .TC macro by allowing it to actually use lowercase Roman numerals
    for the page(s) of the table of contents when a custom title (header or
    footer) is defined containing '%'.
    
    As a side effect, eliminate the PN register, which was apparently
    misused because it was undocumented and had a name just long enough to
    be both suggestive and ambiguous.  Another pin goes into my Ken Thompson
    voodoo doll.
    
    * tmac/s.tmac (IX): Write out page number of index term(s) in using the
      % register (instead of PN), obtaining whatever format is assigned to
      % the register at that time.
      (CH): Similarly, output %, not PN, in the center of the default
      heading.
      (PT): Save the format of %, set it to decimal, copy its value to a new
      register, pg*page-number-in-decimal, then restore %'s previous format.
      Compare the new register, not %, to 1 to determine whether special
      page one behavior should be used.
      (pg*end-page): Assign pg*next-format to %, not PN.
      (XA): Define toc*num with the interpolation of %, not PN.
    
    * tmac/tests/s-TC-works-with-percent-in-custom-titles.sh: Test.
    * tmac/tmac.an (tmac_TEST): Run test.
    
    Problem appears to be very old; as I read it, Larry Kollar was
    complaining of it in his ms.ms document over 20 years ago.
    
    Fixes <https://savannah.gnu.org/bugs/?59345>.


At the time I was not aware that PN was part of ms's documented interface, per
Lesk's 1978-11-13 revision of the ms manual.  Lesk says only this.

"The page number on _output_ is taken from register PN, to permit changing its
output style."

What I _think_ this means is that the assigned format of % cannot be changed
to something other than a decimal format or it will break ms's internal logic
in much the way we saw here in groff ms.  PN exists, apparently, so that
people can .af on it and have their front matter use lowercase roman numerals,
for example.

In groff, we have a register aliasing facility but unfortunately it works
_too_ well; the format as well as the value are aliased, so a clever trick of
creating an alias and then changing the format of the alias does not leave the
original register undisturbed.


.aln PN %
.af % i
.bp
.tm \n%
ii
.tm \n(PN
ii
.af PN 0
.tm \n(PN
2
.tm \n%
2


This leaves us with the yuckier problem of maintaining a PN register in
s.tmac, updating it every time % changes.

Further, the existence and purpose of PN should actually be documented for a
change, both in ms.ms and groff_ms(7).

I haven't marked this as a blocker since conceivably we could ship groff
1.23.0 without fixing it, and even without our dropping of it in NEWS--after
all, PN wasn't working right in the first place, as bug #59345 revealed.  Few
people besides Larry Kollar me seem to have publicly griped about it (and it
took 20 years for me to provide a second instance), and it wasn't documented
in the first place.

I seek opinions about how to proceed.




    _______________________________________________________

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]