Re: Reverting various commits

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Wed, Jun 30, 2021 at 08:32:35PM +1000:
> At 2021-06-28T15:53:48+0200, Ingo Schwarze wrote:

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

That's a fair argument, and another reason for not breaking
non-continuous rendering mode for terminal output (apart from
the generic reason that if any feature is provided, it should
not be broken).

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

I'm not yet sure whether that will indeed be useful in some situations,
but it seems possible that it might be.  I think it will hardly be
a high-priority feature, but if it can be done without relevant
downsides, i don't expect that i would be opposed to it.  Even
though it seems likely that the feature will be fragile, because
how well it will work probably depends on implementation details
of the pager(s)...

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

I think for the purposes of manual pages, working on groff HTML output
is mostly a waste of time because i see no realistic chance of
achieving decent quality, not even if somebody invested huge effort.

That said, i think you are right that for any output mode, silently
dropping text that the document author provided for display is
always a bad idea.

Yours,
  Ingo