Rewrite changelog notes about protected evaluation

Author: lionel-

ChangeLog

@@ -1,27 +1,30 @@
 
 2018-05-31  Lionel Henry  <[email protected]>
 
-	* inst/include/Rcpp/api/meat/Rcpp_eval.h: Unguard Rcpp_fast_eval().
-
-        Unlike Rcpp_eval(), Rcpp_fast_eval() does not evaluate R code within
-        tryCatch() in order to avoid the catching overhead. R longjumps are now
-        correctly intercepted and rethrown. Following this change the C++ stack
-        is now safely unwound when a longjump is detected while calling into R
-        code. This includes the following cases: caught condition of any class,
-        long return, restart jump, debugger exit.
-
-        Rcpp_eval() also uses the protect-unwind API under the hood in order to
-        gain safety. It is fully backward-compatibile and still catches errors
-        and interrupts to rethrow them as typed C++ exceptions. If you don't
-        need to catch those, consider using Rcpp_fast_eval() instead to avoid
-        the catching overhead.
-
-        These improvements are only available for R 3.5.0 and greater. You also
-        need to explicitly define `RCPP_PROTECTED_EVAL` before including Rcpp.h.
-        When compiled with old versions of R, Rcpp_fast_eval() always falls back
-        to Rcpp_eval(). This is in contrast to internal::Rcpp_eval_impl() which
-        falls back to Rf_eval() and which is used in performance-sensititive
-        places.
+        * inst/include/Rcpp/api/meat/Rcpp_eval.h: Fix protected evaluation.
+
+        Setting `RCPP_PROTECTED_EVAL` before including Rcpp.h enables a new R
+        3.5 API for safe evaluation of R code. R longjumps are now correctly
+        intercepted and rethrown. Thanks to this the C++ stack is now safely
+        unwound when a longjump is detected while calling into R code. This
+        includes the following cases: thrown errors, caught condition of any
+        class, long return, restart invokation, debugger exit. Note that this is
+        still experimental!
+
+        When `RCPP_PROTECTED_EVAL` is enabled, Rcpp_eval() uses the
+        protect-unwind API under the hood in order to gain safety. It is fully
+        backward-compatibile and still catches errors and interrupts to rethrow
+        them as typed C++ exceptions. If you don't need to catch those, consider
+        using Rcpp_fast_eval() instead to avoid the catching overhead.
+
+        Rcpp_fast_eval() is a wrapper around Rf_eval(). Unlike Rcpp_eval(), it
+        does not evaluate R code within tryCatch() and thus avoids the overhead
+        of wrapping and evaluating the expression in a tryCatch() call. When
+        Rcpp is compiled with a lower version than R 3.5, Rcpp_fast_eval() falls
+        back to Rf_eval() without any protection from long jumps, even when
+        `RCPP_PROTECTED_EVAL` is set. Either add R 3.5 to your `Depends` or make
+        sure the legacy Rcpp_eval() function is called instead of Rcpp_fast_eval()
+        when your package is compiled with an older version of R.
 
         Note that Rcpp_fast_eval() behaves a bit differently to Rcpp_eval(). The
         former has the semantics of the C function Rf_eval() whereas the latter