Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC830713); site enea.UUCP Path: utzoo!watmath!clyde!burl!ulysses!harpo!decvax!mcvax!enea!kim From: kim@enea.UUCP Newsgroups: net.wanted Subject: Re: looooong page numbers in mm macros - (nf) Message-ID: <218@enea.UUCP> Date: Thu, 15-Mar-84 20:00:21 EST Article-I.D.: enea.218 Posted: Thu Mar 15 20:00:21 1984 Date-Received: Sat, 10-Mar-84 13:20:19 EST Sender: notes@enea.UUCP Organization: ENEA DATA, Sweden Lines: 28 #R:denelcor:-34500:enea:1700003:000:1043 enea!kim Mar 8 09:10:00 1984 << Popular demand by some of our users has caused us to transport the mm << macro package from a System 3 system over to our VAX running 4.2. << Seems to work ok, except for the page number. Nroff seems to like to << make the page number about 80 characters long by left filling it with << zeros. The default header looks like << << - 00000000000000000000000000000000000000000000000000000000000000000000 << 0000000000000005 - This is because mm depends on a sligthly improved version of nroff, which has the new operators \gx and \g(xx returning the .af-type of a number register. mm uses the \g operator to save and restore the format of the P register, and since \g is not defined in 4.x bsd nroff, the format of P is screwed up. I think the \g references only occur in about 8 statements in the whole mm packet, so it is fairly easy to fix. Better still is to transport the nroff of system V to 4.2bsd, because then you also get a macro compaction facility, which reduces the startup time for mm quite a bit. decvax!mcvax!enea!kim