Hello Branden, G. Branden Robinson wrote on Sat, Aug 23, 2025 at 05:21:14PM -0500:
> However, several characters are treated > _transparently_ after the occurrence of an end-of-sentence character. [...] > The default set is '"', ''', ')', ']', '*', '\[dg]', '\[dd]', '\[rq]', > and '\[cq]'. In mandoc, that set is slightly smaller: " ' ) ] These are missing in mandoc: * and the specials dg dd rq cq The difference is not deliberate, but a minor bug in mandoc. I simply wasn't aware yet that there are more eos-transparent characters in groff. > I have a recommendation item for you and a groff man(7) and mdoc(7) > change to propose. > > A. Don't use `\[dq]` here, but don't use `"` either. Use paired > typographical quotation marks, thus. > > A frequently asked question is \[lq]Can I use > .BR free (3) > to free memory allocated with > .BR calloc (3), > or do I need > .BR cfree ()?\[rq] I agree with that recommendation. > Both _groff_ and _mandoc_ correctly degrade these quotation marks to > an ASCII `"` on a device lacking typographer's quotes.[1] > > The rule here, as so often, is to _say what you mean_ and trust the > the formatting system to handle it as best it can. Equivalent code in mdoc(7) would look like this: A frequently asked question is .Do Can I use .Xr free 3 to free memory allocated with .Xr calloc 3 , or do I need .Fn cfree ? .Dc Next sentence. This results in correct inter-sentence spacing with groff, but mandoc only uses an inter-word, not an inter-sentence space, which is another small bug in mandoc. (By the way, the *content* of that sentence is quite ridiculous. Whether calloc(3) needs cfree() is definitely not a frequently asked question. I even had to look up what iBCSe2 is because it is such an arcane thing that i never heard about it, even though i have been doing significant amounts of work in libc. It appears it has been obsolete for at least 20 years, maybe even for up to 30 years, and never was a sane idea in the first place: https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard ) > I therefore propose that _groff_'s man(7) and mdoc(7) packages clear > the `cflags` bit for the `"` character.[2] No objection. Mandoc should eventually follow such a change, which isn't a drama. There is obbious work to do in mandoc in this region anyway. > We don't want inter-sentence space intruding into code examples. Not sure how that could happen. The code would have to contain a double-quote character, then a space character, then another character. For example, .Bd -literal const char *answer = flag ? "yes." : "no."; .Ed does not result in inter-sentence spacing after the "yes." - neither with groff nor with mandoc. So i guess you would have to have the code outside literal context, which is generally a dubious idea at best. The following does result in sentence spacing after the "yes." with both groff and mandoc: .Bd -filled const char *answer = flag ? "yes." : "no."; .Ed But why would anyone use fill mode to input a code sample? I'm not sure i'm able to construct a realistic example that would demonstrate any practical problem. I probably wouldn't make " intransparent because changing existing behaviour usually requires making somethings better that matters in practice - if no clear benefit can be demonstrated, what's the point in risking a regression for some user out there? Then again, i don't feel strongly either way, don't really object, and mandoc would likely eventually follow whatever is decided in this respect. [...] > .BR cfree ()?\[rq] > Subsequent sentence. [...] > $ mandoc -T ascii ATTIC/dq.man [...] > or do I need cfree()?" Subsequent sentence. That's due to mandoc_eos() not (yet) handling special characters, and due to mandoc canceling transparency when the sentence-ending character (e.g., the full stop) is not preceded by an alphanumeric character. The following does result in sentence spacing with mandoc: Do I need cfree?" Subsequent sentence. These do not: Do I need cfree?\(rq \" Special character bug. Subsequent sentence. Do I need cfree()?" \" ? not preceded by isalnum(3). Subsequent sentence. Do I need .BR cfree ()?" \" ? not preceded by isalnum(3). Subsequent sentence. Do I need .BR cfree ?" \" ? not preceded by isalnum(3). Subsequent sentence. The isalnum(3) rule was introduced in this commit: mandoc.c OpenBSD revision 1.15 date: 2010/07/16 00:34:33; author: schwarze; lines: +13 -11; Text ending in a full stop, exclamation mark or question mark should not flag the end of a sentence if: 1) The punctuation is followed by closing delimiters and not preceded by alphanumeric characters, like in "There is no full stop (.) in this sentence" or 2) The punctuation is a child of a macro and not preceded by alphanumeric characters, like in "There is no full stop .Pq \&. in this sentence" jmc@ and sobrado@ like this > I checked, and both commands rendered the document as I expected in a > Latin-1 terminal emulator as well. (_mandoc_ never applies > supplemental inter-sentence space.) Sounds like a slight over-generalization. Yours, Ingo
