doc.topics.beacons: reflow text at 80 chars

doc/topics/beacons/index.rst

@@ -7,8 +7,8 @@ Beacons
 Beacons let you use the Salt event system to monitor non-Salt processes. The
 beacon system allows the minion to hook into a variety of system processes and
 continually monitor these processes. When monitored activity occurs in a system
-process, an event is sent on the Salt event bus that can be used to trigger
-a :ref:`reactor <reactor>`.
+process, an event is sent on the Salt event bus that can be used to trigger a
+:ref:`reactor <reactor>`.
 
 Salt beacons can currently monitor and send Salt events for many system
 activities, including:
@@ -54,8 +54,8 @@ Beacon Monitoring Interval
 --------------------------
 
 Beacons monitor on a 1-second interval by default. To set a different interval,
-provide an ``interval`` argument to a beacon. The following beacons run on
-5- and 10-second intervals:
+provide an ``interval`` argument to a beacon. The following beacons run on 5-
+and 10-second intervals:
 
 .. code-block:: yaml
 
@@ -83,15 +83,14 @@ Avoiding Event Loops
 --------------------
 
 It is important to carefully consider the possibility of creating a loop
-between a reactor and a beacon. For example, one might set up a beacon
-which monitors whether a file is read which in turn fires a reactor to
-run a state which in turn reads the file and re-fires the beacon.
+between a reactor and a beacon. For example, one might set up a beacon which
+monitors whether a file is read which in turn fires a reactor to run a state
+which in turn reads the file and re-fires the beacon.
 
-To avoid these types of scenarios, the ``disable_during_state_run``
-argument may be set. If a state run is in progress, the beacon will
-not be run on its regular interval until the minion detects that the
-state run has completed, at which point the normal beacon interval
-will resume.
+To avoid these types of scenarios, the ``disable_during_state_run`` argument
+may be set. If a state run is in progress, the beacon will not be run on its
+regular interval until the minion detects that the state run has completed, at
+which point the normal beacon interval will resume.
 
 .. code-block:: yaml
 
@@ -247,8 +246,8 @@ in ``/etc/salt/master.d/reactor.conf``:
 
 .. note::
     You can have only one top level ``reactor`` section, so if one already
-    exists, add this code to the existing section. See :ref:`Understanding
-    the Structure of Reactor Formulas <reactor-structure>` to learn more about
+    exists, add this code to the existing section. See :ref:`Understanding the
+    Structure of Reactor Formulas <reactor-structure>` to learn more about
     reactor SLS syntax.
 
 
@@ -286,10 +285,10 @@ constructs from other plugin systems holds true, such as the ``__virtual__``
 function.
 
 The important function in the Beacon Plugin is the ``beacon`` function. When
-the beacon is configured to run, this function will be executed repeatedly
-by the minion. The ``beacon`` function therefore cannot block and should be
-as lightweight as possible. The ``beacon`` also must return a list of dicts,
-each dict in the list will be translated into an event on the master.
+the beacon is configured to run, this function will be executed repeatedly by
+the minion. The ``beacon`` function therefore cannot block and should be as
+lightweight as possible. The ``beacon`` also must return a list of dicts, each
+dict in the list will be translated into an event on the master.
 
 Please see the :py:mod:`~salt.beacons.inotify` beacon as an example.
 
@@ -297,10 +296,10 @@ The `beacon` Function
 ---------------------
 
 The beacons system will look for a function named `beacon` in the module. If
-this function is not present then the beacon will not be fired. This function is
-called on a regular basis and defaults to being called on every iteration of the
-minion, which can be tens to hundreds of times a second. This means that the
-`beacon` function cannot block and should not be CPU or IO intensive.
+this function is not present then the beacon will not be fired. This function
+is called on a regular basis and defaults to being called on every iteration of
+the minion, which can be tens to hundreds of times a second. This means that
+the `beacon` function cannot block and should not be CPU or IO intensive.
 
 The beacon function will be passed in the configuration for the executed
 beacon. This makes it easy to establish a flexible configuration for each
@@ -317,8 +316,8 @@ python dictionaries are preferred, no ordered dicts are needed).
 
 The dictionaries represent individual events to be fired on the minion and
 master event buses. Each dict is a single event. The dict can contain any
-arbitrary keys but the 'tag' key will be extracted and added to the tag of
-the fired event.
+arbitrary keys but the 'tag' key will be extracted and added to the tag of the
+fired event.
 
 The return data structure would look something like this:
 
@@ -337,12 +336,11 @@ available inside the beacon.
 Please be careful when calling functions in `__salt__`, while this is the
 preferred means of executing complicated routines in Salt not all of the
 execution modules have been written with beacons in mind. Watch out for
-execution modules that may be CPU intense or IO bound. Please feel free to
-add new execution modules and functions to back specific beacons.
+execution modules that may be CPU intense or IO bound. Please feel free to add
+new execution modules and functions to back specific beacons.
 
 Distributing Custom Beacons
 ---------------------------
 
 Custom beacons can be distributed to minions using ``saltutil``, see
 :ref:`Dynamic Module Distribution <dynamic-module-distribution>`.
-