Re: Reverting various commits

[Ingo Schwarze]

Hello Branden,

G. Branden Robinson wrote on Sun, Jun 20, 2021 at 07:36:18AM +1000:
> At 2021-05-21T19:28:17+1000, G. Branden Robinson wrote:
>> At 2021-05-20T16:09:59+0200, Ingo Schwarze wrote:
>>> G. Branden Robinson wrote on Thu, May 20, 2021 at 01:23:18AM -0400:

>>>> commit bf4b3dde3ba442a0cf52e986d2549f1dc47f43c5
>>>> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
>>>> AuthorDate: Thu May 20 11:45:10 2021 +1000
>>>> 
>>>>     [mdoc]: Align header/footer spacing with man(7).
>>>>     
>>>>     * tmac/mdoc/doc-common-u (doc-end-macro): When continuously
>>>>       rendering, increase page length by same amount we vertically
>>>>       space after flushing a pending output line, for symmetry
>>>>       with other spacing requests (and to prevent nasty surprises
>>>>       analogous to those in Savannah #60611).
>>>>     
>>>>       (doc-header): Put 3 vees of space after the header in
>>>>       continuous rendering mode, not 1 (and increase page length
>>>>       accordingly).

>>> I very strongly object.  Please revert all recent commits
>>> manipulating mdoc(7) vertical spacing before and after header and
>>> footer lines (i think there was at least one other during the last
>>> one or two days).

>> I can't take this literally.  As part of the above quoted material
>> there is the following.

>>>>     * tmac/mdoc/doc-common-u (doc-end-macro): When continuously
>>>>       rendering, increase page length by same amount we vertically
>>>>       space after flushing a pending output line, for symmetry
>>>>       with other spacing requests (and to prevent nasty surprises
>>>>       analogous to those in Savannah #60611).

>> If you'll take the time to read Savannah #60611[1] I believe you will
>> agree that I found and fixed a rendering problem.  Maybe you'll need
>> to do some experimentation on your own to be convinced.

I didn't mean to ask that bugs remain unfixed.  I'm merely used to
a working regime where, if a regression is found in a commit that
mixes bug fixes with functional changes causing regressions, the
whole commit is reverted, then the pure bug fix recommitted separately.
And my (maybe mistaken, in that case sorry for that) impression was
that more than one of your mdoc commits contrubuted to the regression.

That working mode has two advantages:

 (1) Reverting problematic commits outright is usually much easier and
     quicker than building and testing additional commits on top of
     them.

 (2) The resulting commit history is easier to understand, having the
     commit that mixed good and problematic changes reverted and
     committing the good changes on their own, as opposed to leaving
     the commit that mixes good and problematic changes in, then having
     additional commits on top modifying it.

Sorry for not really making that clear, i admit that my above requests
sound as if i wanted everything ereverted - and remain broken.

>> I sliced my
>> changes very finely while tracking it down and I'm as confident as I
>> can be without contriving an mdoc document exhibiting it--to which I
>> did give some consideration, before deciding that groff_mdoc(7) is
>> sufficiently lengthy and exhibits sufficient exercise of the mdoc(7)
>> feature set that I'd catch regressions in my usual process[2].
> [...]
>> Traditional man(7) never had continuous rendering mode.  As far as I
>> know, in the context of man(7) documents, it's groff's innovation, and
>> we can therefore change it.
>> 
>> I have no objection to doing so; the main reason I didn't was that I
>> didn't want to disturb existing practice.  I get the feeling you'll
>> tell me I respect all the wrong traditions.  ;-)

I'm not yet quite sure what is going on in groff_man(7).  My impression
right now is that by default, for example with

  groff -man -Tascii man/groff.7.man

it no longer prints three blank lines before the beginning of the
"Name" section and before the page footer line.  I actually like
that change and i am quite willing to adjust mandoc to do the same
because these additional two times two blank lines, IMHO, served
little purpose in terminal output and mostly wasted screen real
estate.  Besides, i like making mdoc(7) and man(7) style more similar
to each other.

But i'd like to confirm this is an intentional change before
picking it up for mandoc(1), too.

> I've now taken care of this.  Here is a diff between the relevant macros
> just prior to the commit quoted above, and now.  As I hope is obvious, a
> straight reversion was not appropriate.

Thank you very much.  This looks quite reasonable to me, and testing
with the complete mandoc test suite doesn't indicate any related
regressions any longer with the current content of the groff git repo.

>> Before we (temporarily) depart historical matters, is it your claim that
>> mdoc/BSD nroff innovated "continuous rendering mode"?  I ask simply
>> because I'm curious.

> I remain curious about this.

No, i don't claim such a thing, and i don't know whether that is true
or false.  I would have to investigate, but i'm not enthusiastic
about doing that work.

I realize that non-continuous rendering mode is very important for
PostScript and PDF output, but i don't really care what it does on
the terminal.  I think all that really matters on the terminal is
continuous rendering mode.

In some areas, tradition is of some importance, but i'm not convinced
the differences between continuous and non-continuous rendering mode
are such an area.  I may be missing something, though.

Yours,
  Ingo