From aeac8830f4c369382f46ae733a8d1327b6d3b023 Mon Sep 17 00:00:00 2001
From: root <root>
Date: Fri, 23 Nov 2012 12:52:35 +0000
Subject: *** empty log message ***

---
 ev.pod | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ev.pod b/ev.pod
index f43cc11..e802c9f 100644
--- a/ev.pod
+++ b/ev.pod
@@ -3660,9 +3660,9 @@ already been invoked.
 A common way around all these issues is to make sure that
 C<start_new_request> I<always> returns before the callback is invoked. If
 C<start_new_request> immediately knows the result, it can artificially
-delay invoking the callback by e.g. using a C<prepare> or C<idle> watcher
-for example, or more sneakily, by reusing an existing (stopped) watcher
-and pushing it into the pending queue:
+delay invoking the callback by using a C<prepare> or C<idle> watcher for
+example, or more sneakily, by reusing an existing (stopped) watcher and
+pushing it into the pending queue:
 
    ev_set_cb (watcher, callback);
    ev_feed_event (EV_A_ watcher, 0);
@@ -3680,7 +3680,7 @@ This brings the problem of exiting - a callback might want to finish the
 main C<ev_run> call, but not the nested one (e.g. user clicked "Quit", but
 a modal "Are you sure?" dialog is still waiting), or just the nested one
 and not the main one (e.g. user clocked "Ok" in a modal dialog), or some
-other combination: In these cases, C<ev_break> will not work alone.
+other combination: In these cases, a simple C<ev_break> will not work.
 
 The solution is to maintain "break this loop" variable for each C<ev_run>
 invocation, and use a loop around C<ev_run> until the condition is
-- 
cgit v1.2.3