Larry Jones wrote: > Werner LEMBERG writes: >> I assume there wasn't any other, `official' possibility to >> reset the footnote counter, right? > > Well, there's specifying a second argument to the FD macro which causes > the footnote counter to get reset at each first-level heading, but that > appears to be just as undocumented.
Oh, so that was what the 2nd argument was for! I saw it mentioned, but there was no explanation of the 2nd arg, just that it was normally 1. > Since mm was primarily used inside AT&T where everyone had access to the > source code (with comments!), that was the primary documentation -- > everything else was just supplemental and not kept up to date. If I get > an old mm document from someone, I don't want to have to go on a long > search to figure out what the mysterious number register and string > references mean and what the groff mm equivalents are before I can > format the document with groff, I want it to just work! The existing > macros already have a bunch of backward compatibility aliases for the > most common internals, but I think it behooves us to add more when > references to them turn up in existing documents. However, adding new > aliases is as far as I think we should go -- I wouldn't want to revise > the groff mm implementation just to support backward compatibility if > there isn't already an existing equivalent to alias. > > -Larry Jones > > He's just jealous because I accomplish so much more than he does. -- Calvin BTW, thanks to Keith Marshall - yes, the ".aln :p ft*nr" works; so knowing that ft*nr is the new name for the poorly-documented :p register would allow anyone to easily overcome problems like this. I don't get a vote on the backward compatibility issue, but I think that simply documenting what old registers had known meanings, and listing the new name for them would be perfectly reasonable. They could be introduced with a comment like Keith proposed: "The following table describes best guesses at some undocumented registers, that may not be readily portable to arbitrary troff implementations. :p ft*nr Number register storing the current footnote number. :g ? Number register storing the current list item number. " I also think that if the footnote number register had reset to zero at the start of a new 1st level heading, I wouldn't have even noticed the small problem. So implementing the .FD semantics (and documenting it, now that we know what it did), might be a reasonable thing to do anyway? Regards, luke
