[bug #62825] Incorrect section number using \*($n in a header

[G. Branden Robinson]

Update of bug #62825 (project groff):

                Category:                Macro me => Macro - others/general 

    _______________________________________________________

Follow-up Comment #7:


[comment #6 comment #6:]
> [comment #5 comment #5:]
> > Hmm, every book I've ever seen with section numbers/titles in
> > the header uses the info for the last section on the page.
> 
> You are right; I spoke from ignorance.  I opened an O'Reilly book at random,
and it does indeed populate its headers as you say.

I too have to concur with our anonymous submitter.  I checked the
all-too-short pile of books I have handy.  About half didn't bother to report
section numbers or titles in headers (or footers) at all, but those that did,
published by Springer, MIT, and Prentice-Hall, consistently rendered them as
that person argues.

One of these was the same as in the pile of books I cited recently to
undermine Ingo's claim that the overwhelming majority of publishers in all
fields set headers as mandoc(1) does.

(I'll just let the audacity of that proclamation hang in the air for a
moment.)

> Given that, at a minimum, it seems the -me and -ms documentation ought to at
least mention that the macro packages do not behave as might be expected.
> 
> However, since the problem is (theoretically) fixable -- by deferring the
printing of the header until the end-of-page trap is reached -- arguably the
packages should do this by default.

I reckon what we can do is leave the existing header trap macro names in
place, but change them to just mark the vertical location with `mk`.  The
footer trap can set its own mark, `rt` to the header, call the macro that
actually formats the header, then `rt` to its own place and proceed normally. 
I'll let Branden weigh in here.

I am tempted to call this feature "reflex headers", but unfortunately for me
(if I get it working), it doesn't really need a name at all because it will be
how headers were supposed to work all along.
   
>  There is the very real problem of breaking backward compatibility even if
it does arguably improve output.

It sounds to me like this was just a straight-up bug.  My guess is that people
simply haven't been putting section information in their headers because of
this behavior, they worked around it, or they got lucky.

By coincidence I've been looking at mm(7) today.  If we rope Peter Schaffter
in, we can maybe fix all of our full-service, general-purpose macro packages
in one fell swoop.

Fortunately man pages don't have this problem.  man(7) and mdoc(7) users who
want to buy this trouble for themselves are welcome to do so.
 
> > This is tempting me to boot up my ancient Sun SPARCstation LX
> > running Solaris 2.6, to see if its proprietary version of
> > troff has the same issue.

An LX?  Running 2.6?  We might have this bug fixed before it finishes booting.
 And we don't work fast.

(More seriously, while I love the vintage hardware, my wallet and my storage
unit bill have persuaded me of the value of emulation.)
 
> I'd be very surprised if the -me macros behaved any differently in this
regard: unlike the rest of groff, they weren't reverse engineered in new code,
but used Eric Allman's historical implementation (albeit customized for
groff).  But if you run this experiment and find otherwise, please do report
back here.

I can perhaps confirm a little more easily.  Heirloom Doctools me(7) (vintage
2019 or so) has precisely the same problem.


$ ./bin/nroff -me ../62825.me | ul | cat -s

Chapter 0                 Section                     Page 1
_________________________________________________________________

                         CHAPTER  1

1.1.  Section 1.1

This is the first section.

Chapter 1               Section 1.1                   Page 2
_________________________________________________________________

1.2.  Section 1.2

This is the second section.

Chapter 1               Section 1.2                   Page 3
_________________________________________________________________

1.3.  Section 1.3

This is the third section.




    _______________________________________________________

Reply to this item at:

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

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