X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/putty/blobdiff_plain/350ee89871679a44a2445b52b1f5eb527dd53c77..486f54de20259904c873cdd0369efcd247f40940:/doc/config.but

diff --git a/doc/config.but b/doc/config.but
index b501a319..12ac02bd 100644
--- a/doc/config.but
+++ b/doc/config.but
@@ -356,6 +356,46 @@ If you enable the \q{Application and AltGr act as Compose key}
 option, the Windows Application key and the AltGr key will both have
 this behaviour.
 
+\H{config-bell} The Bell panel
+
+The Bell configuration panel allows you to control how PuTTY should
+respond to a terminal bell.
+
+\S{config-bellstyle} Set the style of bell
+
+When a terminal bell occurs, PuTTY can do one of the following things:
+
+\b Nothing.  The bell is disabled.  Taskbar bell indication still
+works, however.
+
+\b Play Windows Default Sound.  The Windows Default Sound (which can
+be configured from the Sounds control panel) will be played.
+
+\b Play a custom sound file.  Select a \c{.wav} sound file using the
+\e{Custom sound file to play as a bell} text box, or browse for the
+file to play using the \e{Browse...} button.
+
+\b Flash the terminal window as a visual bell.  No sound will be
+played.
+
+In addition, the PuTTY window's title bar and its entry in the taskbar
+can be configured to flash or invert to indicate that a terminal bell
+has occurred.
+
+\S{config-belloverload} Control the bell overload behaviour
+
+Sometimes mistakes, for example trying to \c{cat} a binary file on a
+Unix machine, can lead to a large number of terminal bells being
+received by PuTTY.  It might take a long time for PuTTY to catch up
+with reacting to these bells, and the noise or flashing could be very
+irritating for the user.
+
+PuTTY's bell overload handling is designed to avoid this problem.  If
+turned on using the \e{Bell is temporarily disabled when over-used}
+tick box, the bell will be disabled if it occurs more than a specified 
+number of times in a specified number of seconds.  When no bells have
+occurred for a number of seconds, PuTTY re-enables the bell.
+
 \H{config-window} The Window panel
 
 The Window configuration panel allows you to control aspects of the
@@ -415,6 +455,12 @@ PuTTY window's menu, like clicking on the top left corner. If it is
 disabled, then pressing ALT-Space will just send \c{ESC SPACE} to
 the server.
 
+Some accessibility programs for Windows may need this option
+enabling to be able to control PuTTY's window successfully. For
+instance, Dragon NaturallySpeaking requires it both to open the
+system menu via voice, and to close, minimise, maximise and restore
+the window.
+
 \S{config-altonly} \q{System menu appears on Alt alone}
 
 If this option is enabled, then pressing and releasing ALT will
@@ -490,6 +536,48 @@ more than one type of connection.
 
 \S{config-keepalive} Using keepalives to prevent disconnection
 
+If you find your sessions are closing unexpectedly (\q{Connection
+reset by peer}) after they have been idle for a while, you might
+want to try using this option.
+
+Some network routers and firewalls need keep track of all
+connections through them. Usually, these firewalls will assume a
+connection is dead if no data is transferred in either direction
+after a certain time interval. This can cause PuTTY sessions to be
+unexpectedly closed by the firewall if no traffic is seen in the
+session for some time.
+
+The keepalive option (\q{Seconds between keepalives}) allows you to
+configure PuTTY to send data through the session at regular
+intervals, in a way that does not disrupt the actual terminal
+session. If you find your firewall is cutting idle connections off,
+you can try entering a non-zero value in this field. The value is
+measured in seconds; so, for example, if your firewall cuts
+connections off after ten minutes then you might want to enter 300
+seconds (5 minutes) in the box.
+
+Note that keepalives are not always helpful. They help if you have a
+firewall which drops your connection after an idle period; but if
+the network between you and the server suffers from breaks in
+connectivity then keepalives can actually make things worse. If a
+session is idle, and connectivity is temporarily lost between the
+endpoints, but the connectivity is restored before either side tries
+to send anything, then there will be no problem - neither endpoint
+will notice that anything was wrong. However, if one side does send
+something during the break, it will repeatedly try to re-send, and
+eventually give up and abandon the connection. Then when
+connectivity is restored, the other side will find that the first
+side doesn't believe there is an open connection any more.
+Keepalives can make this sort of problem worse, because they
+increase the probability that PuTTY will attempt to send data during
+a break in connectivity. Therefore, you might find they help
+connection loss, or you might find they make it worse, depending on
+what \e{kind} of network problems you have between you and the
+server.
+
+Keepalives are only supported in Telnet and SSH; the Rlogin and Raw
+protocols offer no way of implementing them.
+
 \H{config-telnet} The Telnet panel
 
 The Telnet panel allows you to configure options that only apply to