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
