[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] tabs in non-literal context

From: Werner LEMBERG
Subject: Re: [Groff] tabs in non-literal context
Date: Fri, 14 Feb 2014 18:54:42 +0100 (CET)

> 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


does *not* work.  Similarly,

  .foo arg1<tab>arg2

doesn't work as expected: `.foo' now has a single argument

And here's another pitfall, directly cited from

  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


             1          2          3                     4          5

Such errors are subtle and probably hard to detect.  For this reasons
I think that the warning is reasonable.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]