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 MullenAs 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?