--- a/chapters/39.markdown Wed Apr 03 22:05:04 2013 -0400
+++ b/chapters/39.markdown Wed Apr 03 22:14:56 2013 -0400
@@ -117,7 +117,7 @@
not familiar with that term, higher-order functions are functions that take
*other* functions and do something with them.
-We'll begin with the trusty "map" function. Add this to your file:
+We'll begin with the trusty `map` function. Add this to your file:
:::vim
function! Mapped(fn, l)
@@ -132,8 +132,8 @@
:let mylist = [[1, 2], [3, 4]]
:echo Mapped(function("Reversed"), mylist)
-Vim displays `[[2, 1], [4, 3]]`, which is the results of applying `Reversed()`
-to every element in the list.
+Vim displays `[[2, 1], [4, 3]]`, which is the result of applying `Reversed()` to
+every element in the list.
How does `Mapped()` work? Once again we create a fresh list with `deepcopy()`,
do something to it, and return the modified copy -- nothing new there. The
@@ -143,8 +143,8 @@
a function") and a list. We use the built-in `map()` function to perform the
actual work. Read `:help map()` now to see how it works.
-Now we'll create a few other common higher-order functions. Add the following to
-your file:
+Now we'll create a few other common higher-order functions. Add the following
+to your file:
:::vim
function! Filtered(fn, l)
@@ -210,10 +210,7 @@
*gigabytes* of RAM.
You'll need to use your own judgement about when this style of programming
-creates unacceptably bad performance. I'd *strongly* encourage you to at least
-give it a fair try though. Using immutable data structures and higher order
-functions can greatly simplify your code and eliminate lots of state-related
-bugs.
+creates unacceptably bad performance.
Exercises
---------
--- a/chapters/41.markdown Wed Apr 03 22:05:04 2013 -0400
+++ b/chapters/41.markdown Wed Apr 03 22:14:56 2013 -0400
@@ -3,7 +3,7 @@
We've covered a lot of ground in the last forty or so chapters. In the final
part of the book we're going to walk through creating a Vim plugin for
-a language from scratch.
+a programming language from scratch.
This is not for the faint of heart. It's going to take a lot of effort.
@@ -11,7 +11,7 @@
to make serious enhancements to your own `~/.vimrc` file and to fix bugs you
find in other people's plugins.
-There's no shame in saying "that's enough for me -- I don't want to spend hours
+There's no shame in saying "that's enough for me, I don't want to spend hours
of my life creating plugins I won't use very often". Be practical. If you
can't think of a full plugin you want to make, stop now and come back when you
do.
@@ -30,19 +30,19 @@
disappearance. It's an extremely small language which makes it ideal for our
purposes.
-Potion feels a lot like [Io][], with some ideas from Ruby, Lua and other
+Potion feels a lot like [Io][], with some ideas from Ruby, Lua, and other
languages mixed in. If you've never tried Io it may seem weird. I strongly
recommend playing with Potion for at least an hour or two. You won't use it in
real life, but it might change the way you think and expose you to new ideas.
The current implementation of Potion has a lot of rough edges. For example: if
-you mess up the syntax it usually segfaults. Try not to get too hung up on this
--- I'll provide you with lots of sample code that works so you can focus mostly
-on the Vimscript and not Potion.
+you mess up the syntax it usually segfaults. Try not to get too hung up on
+this. I'll provide you with lots of sample code that works so you can focus
+mostly on the Vimscript and not Potion.
-The goal is not to learn Potion (though I think doing so *will* make you
-a better programmer). The goal is to use Potion as a small example so we can
-touch on a lot of different aspects of writing Vim plugins.
+The goal is not to learn Potion (though that can be fun too). The goal is to
+use Potion as a small example so we can touch on a lot of different aspects of
+writing full Vim plugins.
Exercises
---------