> since a very long time [1], the mandoc(1) utility throws a warning
> if an input file contains a literal tab character ('\t', ASCII 0x09)
> outside literal context, where literal context is defined as
>
> - .Bd -literal or
> - .Bd -unfilled or
> - .Dl when using -mdoc macros or
> - .nf when using -man macros
I like that :-)
> Now i suspect this warning to be bogus. I checked both the
> Ossanna/Kernighan/Ritter troff manual and the GNU troff online
> manual and found no hint that using tabs outside such contexts
> might cause any problems.
Well, it depends.
> Can anybody confirm that using literal tabs outside the contexts
> listed above in manuals, and in .fi mode in roff in general, is
> just fine, or can anybody think of any reason why literal tabs
> should better be used in .nf mode only?
The very problem is that arguments of requests and macros *must* be
separated by spaces. In other words
.foo<tab>arg
does *not* work. Similarly,
.foo arg1<tab>arg2
doesn't work as expected: `.foo' now has a single argument
`arg1<tab>arg2'.
And here's another pitfall, directly cited from groff.info:
5.1.4 Tab Stops
---------------
`gtroff' translates "tabulator characters", also called "tabs"
(normally code point ASCII `0x09' or EBCDIC `0x05'), in the input
into movements to the next tabulator stop. These tab stops are
initially located every half inch across the page. Using this,
simple tables can be made easily. However, it can often be
deceptive as the appearance (and width) of the text on a terminal
and the results from `gtroff' can vary greatly.
Also, a possible sticking point is that lines beginning with tab
characters are still filled, again producing unexpected results.
For example, the following input
1 2 3
4 5
produces
1 2 3 4 5
Such errors are subtle and probably hard to detect. For this reasons
I think that the warning is reasonable.
Werner
