Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

[G. Branden Robinson]

At 2019-06-30T18:43:31+0200, Ingo Schwarze wrote:
> Sure, paper teletypes is what backspace encoding historically comes
> from.  But that doesn't mean its usefulness is restricted to
> paper teletypes.  In fact, modern pagers handle it just fine.

Yes, but the simple fact is that groff supports applying attributes to
characters that the backspacing semantic model cannot express.

Now, conversely, the backspacing semantic model supports arbitrary
character composition, which glass TTYs and their emulators never do.
(Almost never?  I'd love to hear of any exceptions.)

> That's a non sequitur because i didn't say "use backspace encoding
> because nothing except paper teletypes matters"; i intended to say
> "use backspace encoding because it does the job for most use cases

The context here is the full groff typsesetting system, not just man
pages.  The \m[] and \M[] escapes exist for those who choose to use
them (and give up portability to many or all non-GNU implementations),
for instance when writing a document with ms macros and embedded images
like our doc/wepage.ms[1].

> and avoids the risks involved in allowing terminal escape sequences
> in your pager".  Additional risks from using UTF-8 exist, too, but
> they are relatively minor.

I think you understate the hazards of confusable codepoints in Unicode,
and overstate the hazards of ISO 6429 escape sequences.  We know which
escapes are trouble: those which might inject characters into the input
stream (which is why modern Bash and XTerm and possibly other programs
now support "bracketed paste mode") and those which can collect
information from the host environment.  grotty produces neither of
these.

I grant, however, that risk assessment is a subjective thing.  I
wouldn't support taking away grotty's -c flag.

[..]
> All that said, and given that SGR encoding was already made the
> default in groff at some point in the past,

If I'm reading the history correctly, it came in with groff 1.18, almost
17 years ago (https://ftp.gnu.org/gnu/groff/old/).

> there may not be
> consensus in the groff community for recommending -c more strongly,
> so just describing both modes neutrally, as you did, is probably
> OK after all.

I'll re-review my changes and see if I left anything in nroff that
better belongs in grotty, but I do recall including some arguably
redundant information in the nroff page _because it's a front-end
program_.  There are few reasons to invoke grotty directly, especially
given groff's -P flag.

Regards,
Branden

signature.asc
Description: PGP signature