diff --git a/twander.1 b/twander.1
index 7aedde0..b7899f1 100644
--- a/twander.1
+++ b/twander.1
@@ -1658,15 +1658,15 @@
 a Built-In Variable replacement.  
 
 .TP
-.B REFRESHINT [Numeric] (3000)
+.B REFRESHINT [Numeric] (5000)
 
 Nominal time in milliseconds between automatic directory
 refreshes (if AUTOREFRESH is True).  This time is
 .B really
 nominal and should not be used with any accurate timing
-in mind.  REFRESHINT=5000 says that the refresh
-interval will be nominally 5 seconds (and certainly more
-than the default of 3 seconds), but it can be off this
+in mind.  REFRESHINT=8000 says that the refresh
+interval will be nominally 8 seconds (and certainly more
+than the default of 5 seconds), but it can be off this
 nominal value by quite a bit.  
 
 If you run \*(TW on a slow system (or have a slow link between
@@ -1746,15 +1746,17 @@
 Initial vertical offset of the \*(TW window in pixels.
 
 .TP
-.B USETHREADS [Boolean] (True)
+.B USETHREADS [Boolean] (False)
 
-Normally, \*(TW uses threads to run the commands you've
-defined/entered and requested.  As noted later in the
+\*(TW defaults to using normal "heavy weight" processes
+for running commands on Unix.  Many Unix implementations
+also support a "threaded" process model.  Setting USETHREADS
+to True on such systems will cause \*(TW to use threads, rather than
+processes to launch user-defined commands.  There are some
+known issues with thread-based operations (hence the reason
+this option defaults to False).  These are discussed in the
 .B GOTCHAS
-section, there are circumstances under which this does not
-work properly.  In this case setting USETHREADS=False,
-will cause \*(TW to use more traditional process
-mechanics to run a command.
+section below.
 
 This option applies only to Unix-like operating systems.
 Win32 commands are
@@ -3246,29 +3248,27 @@
 
 .SS Modal Operation Of New Windows
 
-Notice our example commands above do not end with "&". 
-These should not be needed on either Unix-like or Win32
-operating systems.  When a command is executed, \*(TW
-starts a new thread of execution which runs concurrently
-with \*(TW itself.  This means you should be able to
-continue using \*(TW while the new command executes.
-If not (\*(TW is locked out while the new command runs -
-so-called "modal" operation), it means your system does not
-completely or correctly implement threading.  In this case,
-try adding this statement to your \*(CF:
-"USETHREADS=False" which will force \*(TW to 
-invoke new commands using conventional (heavyweight) process
-spawning.
+Notice our example commands above do not end with "&".  These should
+not be needed on either Unix-like or Win32 operating systems.  When a
+command is executed, \*(TW starts a process which runs concurrently
+with \*(TW itself.  This means you should be able to continue using
+\*(TW while the new command executes.  
+
+If you enable the use of threads by setting USETHREADS to True, you
+may see \*(TW locked out while the new command runs - so-called
+"modal" operation.  If this happens, it means your system does not
+completely or correctly implement threading and you must use
+conventional "heavy weight" processes (the default) rather than
+threads.
 
 .SS Windows Don't Disappear On Command Completion
 
 It appears that some X Windows implementations (noted on XFree86 /
 FreeBSD) do not correctly destroy an \'xterm\' window after a command
-initiated with -e terminates.  This is not a \*(TW problem.  The
-workaround is to add the following statement to your Configuration
-File: "USETHREADS=False" This forces conventional (heavyweight)
-process spawning when a command is run.  This mechanism correctly
-destroys the window upon command completion.
+initiated with -e terminates.  This is not a \*(TW problem - it is
+an artifact of thread behavior on such systems and only happens
+if you set USETHREADS=True.   The workaround is to use the default
+USETHREADS=False setting.
 
 .SS Program Behavior Incorrect When A Window Is Resized
 
@@ -3277,7 +3277,7 @@
 seems to not be properly informed that the window size has changed.
 This seems to be an interaction caused by running such programs as
 threads rather than processes.  Once again, the workaround here is
-to set "USETHREADS=False" in the \*(CF.
+to not change the USETHREADS=False default setting.
 
 .SS Really Slow Response Times When Changing To A New Directory