inconsistencies between --man output and --nroff output (when piped to nroff -man)

[jghub]

sort of a very marginal issue, but just to report it:

getopts does allow to convert the internal manpage of a function/script to nroff source by using --nroff rather than --man. if one does something like

print --nroff 2>&1|nroff -man

rather than print --man, one gets the same documentation formatted on screen with certain to be expected differences (line length handling, text justification vs. ragged right) and some not necessarily expected differences regarding emphasis style (on my terminal \a...\a sequences render as bold_underline when looking at --man output but as underlined when formatting the generated nroff source). while this might not be 100% consistent it sure is not of much relevance.

however, I think the following is really buggy: it concerns "group type 6." as described in getopts --man:
6. A group of the form [+\n...] will display the characters representing ... in
fixed-width font without adding line breaks.

which allows to put text in the manpage in "no fill" mode, preserving line layout maintaining all specified line breaks. such text displays just fine on screen with --man but it does not with --nroff|nroff -man. looking at the generated nroff code, it does define its own nroff macros ".DS" and ".DE" to handle this situation and those (for unclear reasons) do not quite what they should. according to groff_man(1) I believe it actually would be better these days to replace .DS .... .DE by the canonical macros .EX .... .EE which essentially do what is intended here. doing this in the --nroff output manually, this fixes at least the random font switches otherwise seen on-screen. furthermore, the emitted nroff code should contain an additional empty line right after the leading .EX to make the formatted output look more similar to that of --man, namely enclosing the displayed text block by leading and trailing vertical space (currently, the leading blank line is missing).