Re: [Groff] tabs in non-literal context

[Werner LEMBERG]

> 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