*** main.c~	Tue Jun  8 13:06:37 1993
--- main.c	Mon Jun 14 15:39:20 1993
***************
*** 24,30 ****
--- 24,32 ----
  #include <sys/file.h>
  #include <sys/time.h>
  #include <sys/ioctl.h>
+ #if !defined (__ultrix)
  #include <sys/stdtypes.h>
+ #endif
  #include <sys/wait.h>
  #include <stdio.h>
  #include <string.h>
*** ytalk.1~	Tue Jun  8 14:23:40 1993
--- ytalk.1	Mon Jun 14 16:22:05 1993
***************
*** 79,86 ****
  invitation for you to call.
  If not,
  .B ytalk
! leaves an invitation for him on
! your machine and tells his talk daemon
  to send an announcement to his screen.
  There is not yet a dedicated
  .B ytalk
--- 79,86 ----
  invitation for you to call.
  If not,
  .B ytalk
! leaves an invitation for the user on
! your machine and tells the user's talk daemon
  to send an announcement to his screen.
  There is not yet a dedicated
  .B ytalk
***************
*** 133,139 ****
  one for each connected user.
  Right now, the number of connected users is limited
  by the number of lines on your terminal (or window),
! for each connected user needs at least four lines.
  The absolute maximum number of connections is set to 20 right now,
  but this can be changed.
  .LP
--- 133,139 ----
  one for each connected user.
  Right now, the number of connected users is limited
  by the number of lines on your terminal (or window),
! as each connected user needs at least four lines.
  The absolute maximum number of connections is set to 20 right now,
  but this can be changed.
  .LP
***************
*** 145,153 ****
  and incorporate the new user.
  If the new user is using
  .SM UNIX
! talk, then information about him will
  .I not
! be transmitted, for his screen would be unable to accept multiple connections.
  I have given brief thought to allowing at least the output of
  .SM UNIX
  talk users to be transmitted to all connected
--- 145,154 ----
  and incorporate the new user.
  If the new user is using
  .SM UNIX
! talk, then information about the user will
  .I not
! be transmitted,
! as the user's screen would be unable to accept multiple connections.
  I have given brief thought to allowing at least the output of
  .SM UNIX
  talk users to be transmitted to all connected
***************
*** 184,191 ****
  from the conversation on the fly.
  Hence, the ESC menu.  Whenever you are using
  .BR ytalk ,
! you can hit the ESCAPE key to bring up a menu which at this
! moment has three options:
  .TP
  .B a
  Add a new user to session
--- 185,192 ----
  from the conversation on the fly.
  Hence, the ESC menu.  Whenever you are using
  .BR ytalk ,
! you can hit the ESCAPE key to bring up a menu which, at this
! moment, has five options:
  .TP
  .B a
  Add a new user to session
***************
*** 270,276 ****
  .br
  Do you wish to talk with user A?
  .br
! and he will be prompted for a yes/no answer.
  This, in my opinion, is much preferable to blitting the announcement
  message and messing up user
  .IR B 's
--- 271,277 ----
  .br
  Do you wish to talk with user A?
  .br
! and he or she will be prompted for a yes/no answer.
  This, in my opinion, is much preferable to blitting the announcement
  message and messing up user
  .IR B 's
***************
*** 299,303 ****
  .SH AUTHOR
  If you have any ideas, comments, or questions,
  I'd be happy to hear from you at <yenne@ccwf.cc.utexas.edu>.
! For all matters regarding encryption, call <miron@extropia.wimsey.com>,
  <neuhaus@informatik.uni-kl.de>, or <pcl@ox.ac.uk>.
--- 300,329 ----
  .SH AUTHOR
  If you have any ideas, comments, or questions,
  I'd be happy to hear from you at <yenne@ccwf.cc.utexas.edu>.
! 
! For all matters regarding encryption within
! .BR ytalk ,
! send email to <miron@extropia.wimsey.com>,
  <neuhaus@informatik.uni-kl.de>, or <pcl@ox.ac.uk>.
+ 
+ .SH BUGS
+ 
+ Sometimes, multiple simultaneous sessions are difficult to set up.
+ For example, user A may be able to talk with both of users B and C,
+ but B and C are unable to talk with each other directly.  In such a
+ case, B and/or C should carry on attempting to set up the connection -
+ it usually works at a subsequent attempt.
+ 
+ Using PGP encryption to swap session keys may make your pass
+ phrase visible to sufficiently competent snoopers.  Caveat emptor.
+ 
+ If PGP fails for some reason, the resulting error messages which are
+ displayed can be enigmatic.
+ 
+ Incomplete, as mentioned above.
+ 
+ The man page is far too chatty for a reference manual.
+ 
+ .SH SEE ALSO
+ 
+ pgp(1), talk(1), talkd(8)
