Re: Reverting various commits

[G. Branden Robinson]

Hi, Ingo!

At 2021-06-28T15:53:48+0200, Ingo Schwarze wrote:
> Hello Branden,
> 
> G. Branden Robinson wrote on Sun, Jun 20, 2021 at 07:36:18AM +1000:
> 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.

Okay--that's fair.  For whatever reason, I've gotten accustomed to
workflows and practices where a revert is seen as a measure of last
resort.  For _me_, the term in a Git context has come to connote
something almost shameful.  That could well be an unhelpful and
inaccurate perception on my part.

> 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 appreciate the clarification.  I agree that the commit in question did
commingle two related but separable concerns.

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

As you noted in your follow-up, this was indeed deliberate and we now
have a pleasant parity between man(7) and mdoc(7) documents in this
respect, whether rendered by groff(1) or mandoc(1).

> >> 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.

It's not a big deal.  I'm happy to give credit where it is due, should
we ever find out who should receive it.

> 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.

I think that's true for most users.  The useful thing about
non-continuous rendering mode to the terminal for me is that no
within-macro-package logic actually cares whether the formatter is
PostScript or PDF, instead, conditionals tend to be predicated on the cR
register instead.  It's much easier for me to catch regressions in
output by diffing text files, so that's what I do.

> 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.

Two or three years ago I played around with adding a PL register to
groff's an-old.tmac to permit the user to tune the page length.  My idea
was that it might be interesting to set it to exactly the height of the
terminal window (or maybe minus one to accommodate less(1)'s prompt), so
that the headers and footers would remain fixed in position, simulating
a page-turning experience.

It almost worked, except there was an off-by-one error somewhere which
ruined things by causing them to drift by one line with each page.  I
couldn't figure it out at the time, but it occurs to me now that one of
the several bugs we had in page location trap management could have been
responsible.  Maybe some day I'll take another crack at it for fun.

I can image a user who might prefer such an experience at the terminal,
however, because it's not _purely_ a matter of fun--one of my gripes
about our HTML output, apart from the rather dire cosmetics that can
occur, is that headers and footers are completely suppressed, which
means most of the information provided to the .TH call is simply not
available.  I'm thinking here of the "extra1" and "extra2" arguments,
which go in the footer and which many projects (including groff) use to
record a project name and modification date.

I noticed that groff's mdoc implementation puts that sort of
information at the page footer even when HTML is output.  I think our
man(7) output should do the same.

I have no immediate plans to do anything about this, but I am curious
what others think.

Regards,
Branden

signature.asc
Description: PGP signature