Re: [Groff] RE: Small bug in groff 1.19.2 footnote number contro

[Luke Kendall]

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