a variety of minor Getting Started edits

Getting-Started/Getting-Started-Custom-Settings.md

@@ -51,7 +51,7 @@ Keys may be defined in a `.scala` file (as described in
 Once you've defined a key, you'll need to use it in some task. You could be
 defining your own task, or you could be planning to redefine an existing
 task. Either way looks the same; if the task has no dependencies on other
-settings or tasks, use `:=` to associate a function with the task key:
+settings or tasks, use `:=` to associate some code with the task key:
 
 ```scala
 sampleStringTask := System.getProperty("user.home)

Getting-Started/Getting-Started-Full-Def.md

@@ -258,7 +258,7 @@ this order:
  - Settings from `.sbt` files in the project.
  - Build definition projects (i.e. projects inside `project`) have
    settings from global plugins (`~/.sbt/plugins`) added.
-   [[using plugins|Getting Started Using Plugins]] explains this
+   [[Using plugins|Getting Started Using Plugins]] explains this
    more.
 
 Later settings override earlier ones. The entire list of settings forms the

Getting-Started/Getting-Started-Multi-Project.md

@@ -142,7 +142,7 @@ To depend on multiple projects, use multiple arguments to `dependsOn`, like
 
 `foo dependsOn(bar)` means that the `Compile` configuration in `foo` depends
 on the `Compile` configuration in `bar`. You could write this explicitly as
-`dependsOn(bar % "compile->compile"`.
+`dependsOn(bar % "compile->compile)"`.
 
 The `->` in `"compile->compile"` means "depends on" so `"test->compile"`
 means the `Test` configuration in `foo` would depend on the `Compile`

Getting-Started/Getting-Started-Summary.md

@@ -27,19 +27,20 @@ to know.
      transforms sbt's collection of key-value pairs into a new collection. It
      doesn't change anything in-place.
    - each setting has a value of a particular type, determined by the key.
-   - _tasks_ are special settings where the computation to produce the key's
+   - _tasks_ are special settings where the computation to produce
-     value will be re-run each time you kick off a task. Non-tasks compute the
+     the key's value will be re-run each time you kick off a
-     value once and cache it.
+     task. Non-tasks compute the value once, when first loading the build
+     definition.
  - [[Scopes|Getting Started Scopes]]
    - each key may have multiple values, in distinct scopes.
    - scoping may use three axes: configuration, project, and task.
-   - a configuration is a kind of build, such as the main one (`Compile`) or
-     the test one (`Test`).
    - scoping allows you to have different behaviors per-project,
      per-task, or per-configuration.
+   - a configuration is a kind of build, such as the main one (`Compile`) or
+     the test one (`Test`).
    - the per-project axis also supports "entire build" scope.
-   - scopes "fall back to" or delegate to more general scopes.
+   - scopes fall back to or _delegate_ to more general scopes.
- - `.sbt` vs. [[.scala|Getting Started Full Def]] build definition
+ - [[.sbt|Getting Started Basic Def]] vs. [[.scala|Getting Started Full Def]] build definition
    - put most of your settings in `build.sbt`, but use `.scala`
      build definition files to
      [[define multiple subprojects|Getting Started Multi-Project]], and to factor out

Getting-Started/Getting-Started-Using-Plugins.md

@@ -129,7 +129,7 @@ Some people like to list plugin dependencies (for a project `hello`) in
 `hello/project/plugins.sbt` to avoid confusion with `hello/build.sbt`.  sbt
 does not care what `.sbt` files are called, so both `build.sbt` and
 `project/plugins.sbt` are conventions. sbt _does_ of course care where
-the sbt files are located. `hello/*.sbt` would contain dependencies for
+the sbt files are _located_. `hello/*.sbt` would contain dependencies for
 `hello` and `hello/project/*.sbt` would contain dependencies for `hello`'s
 build definition.
 
@@ -143,8 +143,8 @@ However, jars intended for use as sbt plugins can do more.
 
 If you download a plugin jar
 ([here's one for sbteclipse](http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.sbteclipse/sbteclipse/scala_2.9.1/sbt_0.11.0/1.4.0/jars/sbteclipse.jar))
-and unpack it with `jar xf`, you'll see that it contains a file `sbt/sbt.plugins`. In `sbt/sbt.plugins`
+and unpack it with `jar xf`, you'll see that it contains a text file `sbt/sbt.plugins`. In `sbt/sbt.plugins`
-there's something like this:
+there's an object name on each line like this:
 
 ```text
 com.typesafe.sbteclipse.SbtEclipsePlugin
@@ -200,11 +200,13 @@ settings in `myPluginSettings` to the project.
 
 ## Creating a plugin
 
-After reading this far, you pretty much know how to _create_ an sbt plugin
+After reading this far, you pretty much know how to _create_ an
-as well. There's one trick to know; set `sbtPlugin := true` in `build.sbt`.
+sbt plugin as well. There's one trick to know; set `sbtPlugin :=
-If `sbtPlugin` is true, the project will scan for instances of `Plugin`,
+true` in `build.sbt`.  If `sbtPlugin` is true, the project will
-and list them in `sbt/sbt.plugins`. `sbtPlugin := true` also adds sbt to the
+scan its compiled classes for instances of `Plugin`, and list them
-project's classpath, so you can use sbt APIs to implement your plugin.
+in `sbt/sbt.plugins` when it packages a jar. `sbtPlugin := true`
+also adds sbt to the project's classpath, so you can use sbt APIs
+to implement your plugin.
 
 Learn more about creating a plugin at [[Plugins]] and [[Plugins Best Practices]].