[bug #63827] withdraw contrib/pdfmark

[G. Branden Robinson]

Follow-up Comment #8, bug #63827 (project groff):

[comment #6 comment #6:]
> [comment #3 comment #3:]
> > ...
> > groff's man pages all have that logic at the top and bottom that
> > takes the body of the page out of compatibility mode, ...
> As already noted in bug #63133 comment #1
<https://savannah.gnu.org/bugs/?63133#comment1>, your code, to do that:
[snip]
> doesn't work on groff-1.22.x and earlier, (because those older groff
versions do not grok the 'cp' register).


.\" Save and disable compatibility mode (e.g., for Solaris 10/11).
.nr _C \n(.C
.do rnn _C *groff_pdfroff_1_man_C
.cp 0


This is similar to something I've had in my man.local for quite a while.


.if \n(.x=1&\n(.y<23 \{
.  \" Construct an equivalent of groff 1.23's .cp register.
.  nr }{ \n(.C
.  do nr .cp \n(}{
.\}


I'm not sure which I like better.  Yours does have appeal.

> I think that we should endeavour to support such older versions, at least
for as long as contemporary software distributions continue to deliver 1.22.x;
thus, unless you can see anything obviously wrong with it, I plan to replace
this, in my pdfroff.1.man, with the following, (as reflected in the attached
patch):
[shown above]
> which does appear to work, on groff-1.22.4 ... at least insofar as it
doesn't raise any warnings, when run with '-ww'.

I see three problems with pursuing this ideal of cleanliness.

1.  As you note, the warning you're trying to avoid is _off_ by default in GNU
troff.  But what's worse, even if you turn it on, the man page librarian may
throw away the standard error output anyway.  man-db man(1) does, and has for
a long time.  You have to run it with a "--warnings=w" flag to get them back. 
I don't know what Brouwer/Lucifredi man (last maintained in 2011, "1.6g") or
proprietary Unix man(1)s do.

2.  You'll want to audit everything in the _tmac_ directory that might
conceivably be loaded when rendering a man page as well (not necessarily just
by the document itself, but _troffrc_ and its descendants).  Several of those
files do the .C dance.

3.  The problem became visible to me because I was trying to get batch
rendering working.  That is, "groff -man foo.1 bar.2 baz.3".  Even setting
aside the matter of compatibility mode entirely, this mode of operation is
horribly broken in all groffs before 1.23.0 going back many years.  I don't
know if it ever worked properly; there were multiple problems and switching
between man(7) and mdoc(7) documents was also implicated (not solely--it
simply made a bad situation worse).  I don't have any handy references for
you, but if you're morbidly curious you can dig through the groff 1.23.0
ChangeLog for the phrase "trap management" to read about some of the worst
bugs.

As it happens I don't even need this in my man.local anymore.  (I had
forgotten it was even there, just like my `MR` fallback, which is how I came
to step on the rake with the problem Alexis noted.)   I wrote a shell function
called "gman" for browsing groff man pages in build trees.


    gman () {
        local width=$(stty size | cut -d' ' -f2)
        width=$(( width - 1 )) # tbl wants one extra character cell
        ./build/test-$(./build/grog -Tutf8 -b -ww -P-i -rU1 \
            -rLL=${LL:-$width}n "$@")
    }


This dogfoods both the formatter and grog(1).


    _______________________________________________________

Reply to this item at:

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

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