tmac/tmac.an: define .MR in a groff compatible way

groff 1.23.0 added .MR to its -man macro package.  The NEWS file states
that the inclusion of the macro "was prompted by its introduction to
Plan 9 from User Space's troff in August 2020."  From d32deab it seems
that the name for Plan 9 from User Space's implementation was suggested
by groff maintainer G. Brandon Robinson.

Not sure if the intention was to make these definitions compatible, but
it would be nice if they were.

Currently, Plan 9 from User Space's .MR expects its second argument to
be parenthesized.  groff's .MR does not.  This results in extra
parentheses appearing in manual references when viewing Plan 9 from User
Space's manual pages on a system using groff.

1 files changed, 15 insertions, 15 deletions

diff --git a/man/man4/factotum.4 b/man/man4/factotum.4
index 02466fcf..282efd8d 100644
--- a/man/man4/factotum.4
+++ b/man/man4/factotum.4
@@ -127,7 +127,7 @@ RSA encryption and signatures, used by SSH and TLS.
 passwords in the clear.
 .TP
 .B vnc
-.MR vnc (1) 's
+.MR vnc 1 's
 challenge/response.
 .TP
 .B wep
@@ -186,7 +186,7 @@ cpu server.  On starting, it will attempt to get a
 key from NVRAM using
 .B readnvram
 (see
-.MR authsrv (3) ),
+.MR authsrv 3 ),
 prompting for anything it needs.
 It will never subsequently prompt for a
 key that it doesn't have.
@@ -245,7 +245,7 @@ specific to each supported protocol.
 .PP
 All keys can have additional attibutes that act either as comments
 or as selectors to distinguish them in the
-.MR auth (3)
+.MR auth 3
 library calls.
 .PP
 The factotum owner can use any key stored by factotum.
@@ -305,7 +305,7 @@ such as
 and
 .B auth_challenge
 (see
-.MR auth (3) )
+.MR auth 3 )
 to specify which key and protocol to use for an authentication.
 Like a key tuple, a key template is also a list of
 .IB attribute = value
@@ -367,7 +367,7 @@ turned on by the
 option.
 .PP
 By default when factotum starts it looks for a
-.MR secstore (1)
+.MR secstore 1
 account on $auth for the user and, if one exists,
 prompts for a secstore password in order to fetch
 the file
@@ -385,7 +385,7 @@ sets a public/private keypair for ssh authentication,
 generated by
 .B ssh_genkey
 (see
-.MR ssh (1) ).
+.MR ssh 1 ).
 .PD
 .SS "Confirming key use
 .PP
@@ -481,11 +481,11 @@ RPC's) until done
 if successful, reading back an
 .I AuthInfo
 structure (see
-.MR authsrv (3) ).
+.MR authsrv 3 ).
 .PP
 The RPC protocol is normally embodied by one of the
 routines in
-.MR auth (3) .
+.MR auth 3 .
 We describe it here should anyone want to extend
 the library.
 .PP
@@ -545,7 +545,7 @@ necessary
 authentication has succeeded, an
 .B AuthInfo
 structure (see
-.MR auth (3) )
+.MR auth 3 )
 can be retrieved with an
 .B authinfo
 RPC
@@ -703,7 +703,7 @@ and
 are intended to be proxied via
 .I auth_proxy
 (see
-.MR auth (3) ).
+.MR auth 3 ).
 .\" The protocols follow
 .\" .IR p9any (7)
 .\" and
@@ -736,7 +736,7 @@ before being sent over the network.
 .PP
 .I Vnc
 is the challenge-response protocol used by
-.MR vnc (1) ;
+.MR vnc 1 ;
 valid roles are
 .B client
 and
@@ -840,7 +840,7 @@ a string: a space-separated quoted user name and password
 that can be parsed with
 .I tokenize
 (see
-.MR getfields (3) ).
+.MR getfields 3 ).
 Conventionally, client keys have distinguishing attributes
 like
 .B service
@@ -905,7 +905,7 @@ and
 .BR !dk
 specifying the private half of the key;
 see
-.MR rsa (3) .
+.MR rsa 3 .
 Conventionally,
 .I rsa
 keys also have
@@ -972,7 +972,7 @@ attributes.
 If the key is to be used for signing, it must also have a
 .B !secret
 attribute; see
-.MR dsa (3) .
+.MR dsa 3 .
 Conventionally,
 .I dsa
 keys
@@ -1019,4 +1019,4 @@ The response is a hexadecimal string of length 32.
 .SH SOURCE
 .B \*9/src/cmd/auth/factotum
 .SH SEE ALSO
-.MR ssh-agent (1)
+.MR ssh-agent 1