Hi Claudio and Todd,
Todd C. Miller wrote on Thu, Jul 15, 2021 at 02:01:23PM -0600:
> You are expected to know that ^I (control-I) is the tab character.
> Using ^I instead of a literal tab character in the manual was
> supposed to make it clear that this is a tab and not a series of
> spaces but maybe it is not so obvious...
You aren't even expected to know; "I" being the ninth letter of the
alphabet, hence ^I = 0x09 = ht not necessarily being obvious is the
reason why the manual page already explains it explicitely, it
says:
Put a tab after the first word, i.e., use `int^Ix;'
and `struct^Ifoo *x;'.
So i think the OP's patch is wrong.
It is also wrong because using a literal tab character in roff(7)
input in filled mode is discouraged roff(7) syntax:
$ printf 'foo\tbar' | mandoc -Tlint
mandoc: <stdin>:1:4: WARNING: tab in filled text
$ man mandoc
[...]
DIAGNOSTICS
[...]
tab in filled text
(mdoc, man) The meaning of tab characters is only well-defined in non-
fill mode: In fill mode, whitespace is not supposed to be significant on
text input lines. As an implementation dependent choice, tab characters
on text lines are passed through to the formatters in any case. Given
that the text before the tab character will be filled, it is hard to
predict which tab stop position the tab will advance to.
So to use "int<literal tab>x", that string would have to be set in
unfilled mode. And exactly that is already there, right below:
struct foo {
struct foo *next; /* List of active foo */
struct mumble amumble; /* Comment for mumble */
int bar;
};
That struct display does contain literal tabs in the mdoc(7) source
code, as indeed it should.
Yes, tabs versus spaces is a royal PITA in Unix in general.
That long-standing source of confusion wasn't mitigated until
much later, when the Python programming language was invented.
Yours,
Ingo
