At 2025-02-16T02:44:12+0100, onf wrote: > On Sun Feb 16, 2025 at 2:09 AM CET, G. Branden Robinson wrote: > > At 2025-01-29T00:57:19-0400, sebastien peterson boudreau wrote: > > > The quotes for `i'th and `i+1'th are very important because the > > > parser will reject input that uses two right/neutral > > > quotes/apostrophes. > > > > You're right! Back in November 2020, I "corrected" this example. > > [...] > > Obviously the `oq` and `cq` special characters aren't correct, but I > > knew very little about pic(1) at the time and didn't understand that > > it really does use m4/TeX/troff-style quotation syntax for its > > embedded expressions. I find the decision odd, but I'm probably > > decades late to weigh in on it. > > Seems like you found yourself in a familiar situation: > "This under-documented code seems stupid. Was the person who wrote it > really that stupid, or am I missing something?"
Predictably, I would not be as hard on myself as you are on me. I didn't think the original code was "stupid", merely mistaken in special character selection with respect to getting the desired quotes, and I already knew more than 5 years ago that correct selection stymied many people.[1] It's an even worse problem than many people appreciate at first, in part because ASCII--ANSI X3.4--explicitly license[sd] ambiguous semantics and rendering for quote-like characters (and others!), and people who haven't educated themselves in the history of character encoding standards think that ASCII is a strict subset of ISO Latin-1 (8859-1) which is in turn a strict subset of Unicode. That's so close to true that people blunder into the persnickety exceptions with sensitive parts of their bodies. But mistakes in this area also arise due to a Debian patch to groff (though I think it may have originated here) that got cargo-culted around several distributions to conceal errors in man(7) documents. https://gitlab.com/procps-ng/procps/-/merge_requests/213/diffs?commit_id=a3ac4b667929320d4c8012435d63a9d1dd538a8d When your distributor hides your mistakes from you, you're less likely to see them. Felipe Contreras has an instructive write-up regarding another man(7) problem arising from similar factors, one that fortunately seems to be dying out. https://felipec.wordpress.com/2021/06/05/adventures-with-man-color/ > Experience has taught me to approach seemingly non-sensical code with > caution. Contrastingly, experience has taught me to test examples before sticking them into a man page, and to test the ones that are already there by copy-and-pasting them, before assuming they're correct. This recourse might have been thought unnecessary by the drafters of the GNU pic(1) page, which unfortunately is one of our "diff" pages (like eqn(1)[2]) that documents only GNU extensions to AT&T pic (relative to Eighth Edition Unix pic, I think), and presumes that the reader is already a sophisticated pic user. Regards, Branden [1] Here's a huge thread from January-February 2019. https://lists.gnu.org/archive/html/groff/2019-01/msg00063.html https://lists.gnu.org/archive/html/groff/2019-02/msg00003.html [2] ...and like groff_diff(7), but that page is fine in my view because it is frank about what it doesn't do, and we have more complete documentation elsewhere.
signature.asc
Description: PGP signature
