At 2022-09-26T15:40:39-0500, G. Branden Robinson wrote: > > less interprets b^Hbo^Hol^Hld^Hd by outputting the correct escape > > sequences for the terminal in use. > > No, it doesn't, and cannot, because that representation form is > ambiguous when the character to be overstruck is an underscore. This > actually comes up in man pages. Somewhere in the Debian BTS there is > an exhibit from a real page about this, but I don't recall right now > where.
I found it. Mark Wooding pointed this out in 2020. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963490#5 I was wrong about Mark supplying a specimen from a real-world man page, but he did offer a reproducer which enabled me to find a few. Here's a more full reproducer (it still doesn't take much). Remember, for this to behave badly you _have_ to use the celebrated SGR disablement feature. .TH demo 1 2022-09-26 "a demonstration" .IB x _mid_ y In the output you will see that the first underscore is underlined ("italicized") while the second is boldfaced. Obviously from the macro arguments they should both be bold. On my Debian bullseye system, ul(1) seems to guess better with this input than less 581.2 does. (I use a more recent version of less because I needed it to test grotty's OSC 8 support.) With the overstriking approach there is simply no way around this guesswork. One could of course propose some sort of in-band signaling protocol utterly alien to the fluttering standard of the Teletype Model 37 around which opponents of grotty's SGR output have rallied. The cowpoke(1) man page in Debian offers several exhibits of misrendering arising from this ambiguity. Here's one paragraph. SIGN_KEYID If this option is set, it is expected to contain the gpg key ID to pass to debsign(1) if the packages are to be remotely signed. You will be prompted to confirm whether you wish to sign the packages after all builds are complete. If this option is unset or an empty string, no attempt to sign packages will be made. It may be overridden on an arch and dist specific basis us‐ ing the arch_dist_SIGN_KEYID option described below, or per‐invocation with the --sign command line option. This email strips typeface changes, of course, but anyone wanting to continue to prosecute their mistaken and erroneous position regarding this groff feature can observe that the underscores after "arch" and "dist" are underlined ("italicized") when they should be bold. Observe the page source. made. It may be overridden on an \fIarch\fP and \fIdist\fP specific basis using the .IB arch _ dist _SIGN_KEYID option described below, or per-invocation with the \fB\-\-sign\fP command line option. Here are some other pages worth investigating. /usr/share/man/man1/pamdice.1.gz /usr/share/man/man1/winicontoppm.1.gz /usr/share/man/man7/lvmraid.7.gz I emphasize that there's nothing incorrect about the man page source code above. Pages misrender because overstriking for font changes is an inherently limited and ambiguous convention that simply cannot reliably produce correct output in some cases. If you want correctness, enable SGR. > As much as I'd like to think that some grief could have been avoided > by naming grotty something like "groansi" instead, I suspect the > amount would be vanishingly small. From what I've seen, users > scandalized by the violence that less(1) does to grotty's output do > not, as a first recourse, research the problem. Instead they file > bugs like this one. > > Nevertheless, I have given serious consideration to making grotty(1) > use the terminfo library to determine terminal capabilities; its > current approach is admittedly crude. It seems like it would be > friendly to users to _ask_ their terminals, or at least their $TERM > variables, what they claim to be capable of. I should add that even if I do this, I don't expect _any_ observable reduction in the number of complaints. xterm (and ncurses) maintainer Thomas Dickey's website regales the reader with story after story of users (and GNU/Linux distributions) who changed TERM environment variable settings and terminal database descriptions, practicing their marksmanship, if not blindly, then in terribly low light. The problem is that the set of people who hate the fact that grotty produces SGR considerably overlaps the set of people who clamored for 256-color (and subsequently "true color") support in xterm, because they wanted skinnable color schemes for Vim and similar. (Admittedly, some of the pressure in this area was relieved when the Atom IDE came along and skimmed a lot of these people off.) The people in the large intersection of these sets want simultaneous fidelity to ultra-modern xterm on the one hand and the Teletype Model 37 on the other. The possibility that this is fundamentally impossible they meet with QAnon levels of denial. Most users of POSIX systems undertake quick hacks to attack problems; some of them, when they evaluate a sample size of one, believe themselves to have undertaken engineering. That's a delusion of Dunning-Krueger overconfidence. Touting themselves to prospective employers with implications of their status as rock star programmers, to the more jaundiced eye they appear as ignorant braggarts, the cluenessness pouring like syrup from their slack faces. Imagine someone reopening this; I risk telling them how I _really_ feel. Regards, Branden
signature.asc
Description: PGP signature
