Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!zehntel!hplabs!sri-unix!mullen@NRL-CSS.ARPA
From: mullen@NRL-CSS.ARPA
Newsgroups: net.unix
Subject: Re:  why no .li in ditroff?
Message-ID: <12154@sri-arpa.UUCP>
Date: Tue, 18-Sep-84 18:26:00 EDT
Article-I.D.: sri-arpa.12154
Posted: Tue Sep 18 18:26:00 1984
Date-Received: Wed, 26-Sep-84 01:09:48 EDT
Lines: 30

From:  Preston Mullen 

As you noted, .li appears in the index of the old TROFF manual.  I think
I learned about it from someone who had used an earlier version of TROFF
when it was properly documented.

I assume that .li is mnemonic for "literal".  With regular TROFF,
	.li N
causes the next N lines (default 1) to be read literally, in a sense.
I recently examined the code to see what this really means.  It looks
like all it does is to:

1.  treat requests as ordinary text, e.g.
	.sp 4
    prints as
	.sp 4
    instead of as four blank lines, and

2.  ignore transparent mode, so that text preceded by \! is processed
    as if the \! were not there.

The Typesetter-Independent TROFF now being delivered has no .li request.

I can get the desired effect using .cc and .c2, but then I have to pick
a suitable argument for these requests that won't appear in the input.
Using ".li" was easier and, I think, safer.

I don't really see why it had to be removed; the change broke some of
my TROFF macros.  Could this have been part of making transparent mode
work properly?