"G. Branden Robinson" <[email protected]> writes: > At 2025-08-24T13:55:29-0700, Russ Allbery wrote:
>> The position I have taken in Pod::Man is that people writing pure ASCII >> POD should use " for quotation marks (not `` or '' or anything else). >> That character is then copied directly to the output (with escaping as >> necessary for macro arguments). At present, this produces reasonable >> behavior with groff. Earlier versions of Pod::Man attempted to do other >> things to enable typographic paired quotes, and those efforts were a >> fragile maintenance disaster with all sorts of failing edge cases. All >> of that code was removed in 5.00 and v6.0.0. > That's fine, and is consistent with the presumption that underlies my > proposed change: most of the time, in man pages, authors use `"` for > some purpose other than prose quotation. Well, what I'm trying to say here is that this presumption may be true for man pages that authors write directly in *roff and use `` and '' as originally intended, but in the universe of man pages that include ones generated from POD, I am dubious about that presumption. It is common in POD source to use `"` for prose quotation, and Pod::Man will preserve that usage in the generated *roff. >> I think you are making an assumption that " in *roff input is mostly >> only used for code. > Not quite. I'm making the assumption that " _in man(7) and mdoc(7) > input_ is mainly used for code. If by "mainly" you mean 55%, sure, maybe. I have no statistics. If by "mainly" you mean more like 90%, I'm dubious. We've lived with the rare misformatting of code for many years. It's rare in part because the `."` sequence, while not impossible in code, is not common. I don't think it's a good approach to trade that misformatting for what I believe will be more common misformatting of text. I continue to be surprised that .nf does not disable this type of reformatting. I believe you that this is how *roff has always worked, but it sure feels to me like how *roff has always worked is incorrect. :) Personally, I'd rather see you change that behavior than to make `"` non-transparent for sentence boundaries. I think that change would eliminate most of the problem cases for code blocks, since at least IMO it's poor style to inline complex expressions involving quotes rather than setting them off in what in POD we'd call a verbatim paragraph. I'm also not seeing a drawback to that change. Obviously that would be a lot more work, though, and I certainly understand why you wouldn't want to do it. Meanwhile, I think I prefer the status quo. >> This is probably true for the universe of documents written directly >> in *roff, since that has (always?) been part of the *roff language, >> but it's false for the universe of *roff generated from POD, where " >> is used for nearly all English double quotation marks. I believe >> making this change is quite likely to result in inconsistent sentence >> spacing for lots of existing *roff output. > The `Dq` string change, I assume you mean, not the `cflags 0 "` change. No, I mean the `cflags 0 "` change. > I disagree with this lament, and strike a note of less futility in > groff_man_style(7). > ---snip--- > /.../share/groff/site-tmac/man.local > Put site‐local changes and customizations into this file. > .\" Put only one space after the end of a sentence. > .ss 12 0 \" See groff(7). > .\" Keep pages narrow even on wide terminals. > .if n .if \n[LL]>80n .nr LL 80n > ---end snip--- > (That's /etc/groff/man.local in Debian-based systems.) This doesn't help. That solves a different problem, which is to display one space after periods when reading man pages on your own system. When *writing* POD, one obviously cannot go and add this change to *other people's* systems, and therefore one has to take irritating and inobvious special measures to format the input such that *roff can recognize the sentence boundaries if one wants the sentence spacing to be consistent on systems that have not made this change to the defaults. Or, if one wants your text to render with one space after periods on arbitrary systems that you cannot reconfigure (which, I agree, may not be a good thing to want, but I certainly do have users who want that and who have complained to me about it), one has to take different and even more annoying and inobvious special measures to interfere with *roff's ability to recognize sentence boundaries. This is tedious and irritating and therefore mostly doesn't happen. It's hard enough to get people to write documentation of any kind, let alone adopt what seems to them as unnatural prose formatting. Therefore, many man pages translated from POD (and ones not translated from POD, for that matter) are routinely rendered with spacing inconsistencies. I've somewhat made my peace with this and mostly assume this is unfixable because the necessary measures on the author's side are too annoying to be viable for most authors. Maybe eventually everyone will just feed text through a machine learning model trained to recognize sentence boundaries and insert special markup. :) But at least, in the current system, an author who *wants* to get this right can get 99% of the way there by adopting a policy of adding a line break after each sentence. If I understand the proposal correctly, the `cflags 0 "` change would make the problem much worse, since there would no longer be a way to tell *roff to consistently space a sentence ending with `."`, even by adding line breaks after sentences. When groff reflows the paragraph, it will always treat `."` as the end of a regular word, not a sentence, and space it accordingly. The *only* option for correct sentence spacing consistent with the defaults, when writing in POD, would be to use Unicode quotes, with all the tedium that involves on many systems and keyboard entry methods. Maybe I still misunderstand something? -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
