tmac: introduce real manual reference macro instead of overloading IR

The overloading of IR emits magic \X'...' sequences that turn into HTML manual links.
But not all such IR invocations should be manual links;
those had to be written to avoid the IR macro before.
Worse, the \X'...' ending the IR causes troff to emit only a single space after a period.

Defining a new IM macro for manual references fixes both problems.

Fixes #441.

1 files changed, 36 insertions, 36 deletions

diff --git a/man/man4/factotum.4 b/man/man4/factotum.4
index 3a2d3d7c..453965df 100644
--- a/man/man4/factotum.4
+++ b/man/man4/factotum.4
@@ -10,7 +10,7 @@ factotum \- authentication agent
 ] [
 .B -s
 .I srvname
-] 
+]
 .\" [
 .\" .B -m
 .\" .I mtpt
@@ -79,7 +79,7 @@ same user id as it.  For select protocols such as
 it can also act as a client for other processes provided
 its user id may speak for the other process' user id (see
 Plan 9's
-\fIauthsrv\fR(6)).
+.IR authsrv (6)).
 .I Factotum
 can act in the role of server for any process.
 .PP
@@ -127,7 +127,7 @@ RSA encryption and signatures, used by SSH and TLS.
 passwords in the clear.
 .TP
 .B vnc
-.IR vnc (1)'s
+.IM 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
-.IR authsrv (3)),
+.IM authsrv (3) ),
 prompting for anything it needs.
 It will never subsequently prompt for a
 key that it doesn't have.
@@ -227,7 +227,7 @@ the kernel at boot time.
 .PP
 A
 .I "key tuple
-is a space delimited list of 
+is a space delimited list of
 .IB attribute = value
 pairs.  An attribute whose name begins with an exclamation point
 .RB ( ! )
@@ -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
-.IR auth (3)
+.IM auth (3)
 library calls.
 .PP
 The factotum owner can use any key stored by factotum.
@@ -305,9 +305,9 @@ such as
 and
 .B auth_challenge
 (see
-.IR auth (3))
+.IM 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 
+Like a key tuple, a key template is also a list of
 .IB attribute = value
 pairs.
 It must specify at least the protocol and enough
@@ -367,7 +367,7 @@ turned on by the
 option.
 .PP
 By default when factotum starts it looks for a
-.IR secstore (1)
+.IM secstore (1)
 account on $auth for the user and, if one exists,
 prompts for a secstore password in order to fetch
 the file
@@ -385,11 +385,11 @@ sets a public/private keypair for ssh authentication,
 generated by
 .B ssh_genkey
 (see
-.IR ssh (1)).
+.IM ssh (1) ).
 .PD
 .SS "Confirming key use
 .PP
-The 
+The
 .B confirm
 file provides a connection from
 .I factotum
@@ -397,7 +397,7 @@ to a confirmation server, normally the program
 .IR auth/fgui .
 Whenever a key with the
 .B confirm
-attribute is used, 
+attribute is used,
 .I factotum
 requires confirmation of its use.  If no process has
 .B confirm
@@ -429,7 +429,7 @@ the same user id as
 .IR factotum .
 .SS "Prompting for keys
 .PP
-The 
+The
 .B needkey
 file provides a connection from
 .I factotum
@@ -481,11 +481,11 @@ RPC's) until done
 if successful, reading back an
 .I AuthInfo
 structure (see
-.IR authsrv (3)).
+.IM authsrv (3) ).
 .PP
 The RPC protocol is normally embodied by one of the
 routines in
-.IR auth (3).
+.IM 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
-.IR auth (3))
+.IM auth (3) )
 can be retrieved with an
 .B authinfo
 RPC
@@ -621,7 +621,7 @@ is expected to be a long hexadecimal string.
 These are useful for manually debugging of binary protocols.
 .TP
 .B authinfo
-retrieve the AuthInfo structure.  
+retrieve the AuthInfo structure.
 The possible replies are:
 .RS
 .TP
@@ -661,7 +661,7 @@ with its own roles and required key attributes.
 and
 .I p9cr
 are used to authenticate to Plan 9 systems;
-valid 
+valid
 .BR role s
 are
 .B client
@@ -691,7 +691,7 @@ is a meta-protocol that negotiates a protocol
 .RB ( p9sk1
 or
 .BR p9sk2 )
-and an authentication domain and then invokes the 
+and an authentication domain and then invokes the
 given protocol with a
 .B dom=
 attribute.
@@ -703,7 +703,7 @@ and
 are intended to be proxied via
 .I auth_proxy
 (see
-.IR auth (3)).
+.IM 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
-.IR vnc (1);
+.IM vnc (1) ;
 valid roles are
 .B client
 and
@@ -746,7 +746,7 @@ The client protocol requires a
 key with attribute
 .BR !password .
 Conventionally, client keys also have
-.B user 
+.B user
 and
 .B server
 attributes.
@@ -763,7 +763,7 @@ except that the challenge and response are not textual.
 and
 .I cram
 are challenge-response protocols typically
-used to authenticate 
+used to authenticate
 to mail servers.
 The client protocols require
 .B proto=apop
@@ -774,7 +774,7 @@ keys with
 and
 .B !password
 attributes.
-Conventionally, client keys also have 
+Conventionally, client keys also have
 .B server
 attributes.
 The server protocol requires a
@@ -828,7 +828,7 @@ structure (defined in
 .PP
 .I Pass
 is a client-only protocol that hands out passwords
-from 
+from
 .B proto=pass
 keys with
 .B user
@@ -840,7 +840,7 @@ a string: a space-separated quoted user name and password
 that can be parsed with
 .I tokenize
 (see
-.IR getfields (3)).
+.IM getfields (3) ).
 Conventionally, client keys have distinguishing attributes
 like
 .B service
@@ -860,7 +860,7 @@ keys with
 .BR !key2 ,
 or
 .B !key3
-attributes.  
+attributes.
 The protocol with
 .I factotum
 is:
@@ -873,7 +873,7 @@ opens the device's control file, sets the wireless secret using the key,
 and turns on encryption.
 If the key has an
 .B essid
-attribute, 
+attribute,
 .I factotum
 uses it to set the wireless station ID.
 .PP
@@ -891,7 +891,7 @@ uses
 keys with
 .B ek
 and
-.B n 
+.B n
 attributes, large integers specifying the public half
 of the key.
 If a key is to be used for decryption or signing,
@@ -905,13 +905,13 @@ and
 .BR !dk
 specifying the private half of the key;
 see
-.IR rsa (3).
+.IM rsa (3) .
 Conventionally,
 .I rsa
 keys also have
 .B service
 attributes specifying the context in which the key is used:
-.B ssh 
+.B ssh
 (SSH version 1),
 .B ssh-rsa
 (SSH version 2),
@@ -946,7 +946,7 @@ and
 The hash function must be known to
 .I factotum
 because the signature encodes the type of hash used.
-The 
+The
 .B encrypt
 and
 .B verify
@@ -972,11 +972,11 @@ attributes.
 If the key is to be used for signing, it must also have a
 .B !secret
 attribute; see
-.IR dsa (3).
+.IM dsa (3) .
 Conventionally,
 .I dsa
 keys
-also have 
+also have
 .B service
 attributes specifying the context in which the key is used:
 .B ssh-dss
@@ -992,7 +992,7 @@ Unlike
 .IR rsa ,
 the
 .I dsa
-protocol ignores the 
+protocol ignores the
 .B hash
 attribute; it always uses SHA1.
 .PP
@@ -1019,4 +1019,4 @@ The response is a hexadecimal string of length 32.
 .SH SOURCE
 .B \*9/src/cmd/auth/factotum
 .SH SEE ALSO
-.IR ssh-agent (1)
+.IM ssh-agent (1)