Removed some line breaks to deal with a bug in the guides gem

source/commit_code.textile

@@ -91,8 +91,7 @@ This test sucks because it only verifies that you can set a property on an objec
 
 TIP: For more information see "Writing Unit Tests":writing_unit_tests.html.
 
-
-h4. Running unit tests
+h4. Running Unit Tests
 
 You can run the unit tests by using the test runner app +http://localhost:4020/sproutcore/tests+ or by calling them manually:
 

source/contribute.textile

@@ -124,8 +124,7 @@ Pushing your changes back to the remote repository:
 $ git push origin <branchName>
 </shell>
 
-TIP:  branchName above is the name you used at the beginning of the guide in the git checkout step.  If you can't remember the name use 'git branch -a' to list the branches. 
-
+TIP:  branchName above is the name you used at the beginning of the guide in the git checkout step.  If you can't remember the name use 'git branch -a' to list the branches.
 
 Next, submit a pull request from your repository. Make sure to make the pull request using the branch you used for the guide.
 

source/core_concepts.textile

@@ -404,10 +404,8 @@ When working with unit tests, you will also have situations where you need to fo
 
 You may also find that when you are working in your browser's JavaScript console that, when you set a variable, your app's interface doesn't update as you expect. This may be caused by the run loop not firing (since you aren't interacting directly with the app no events are being triggered). In this case you should try invoking the run loop manually, or just move your mouse over the app to trigger a new event.
 
-
 WARNING: Remember, you rarely need to manage the run loop manually from within your app. If you aren't certain of why you are using it, then you are probably doing something wrong. The average user should use the run loop only in Unit Tests or in the console.
 
-
 h3. Changelog
 
 * January 12, 2011: initial partial version by "Peter Wagenet":credits.html#pwagenet

source/fixtures.textile

@@ -165,7 +165,6 @@ MyApp = SC.Application.create({
 
 TIP:  Notice the quotes around the data source name?  +MyApp.MyAppsFixturesDataSource+ doesn't exist until its instantiated during the loading process.
 
-
 h3. Changelog
 
 * January 11, 2011: initial version by "Peter Wagenet":credits.html#pwagenet

source/records.textile

@@ -287,9 +287,6 @@ MyApp.Contact = SC.Record.extend({
 
 NOTE: If you use +set()+ on an undefined property, SproutCore by default will pass the value through to the underlying data hash. You can turn this behavior off by setting +ignoreUnknownProperties: YES+ in your model classes.
 
-
-
-
 h3. Using Your Models
 
 Now that we have defined our +Contact+ and +Address+ models it's time to actually create some records. All records are managed by the store, so we have to make sure first that we have an instance of +SC.Store+ available. Usually the store is instantiated somewhere in your application's "core.js" file:
@@ -406,9 +403,6 @@ if (status === SC.Record.READY_NEW) {
 
 NOTE: For a complete list of record state constants see the "documentation of the SC.Record class":http://docs.sproutcore.com/symbols/SC.Record.html.
 
-
-
-
 h3. Finding Records in the Store
 
 Because the store manages all records in memory, you can query it for records of a certain type, records with a certain id or more complex search criteria.
@@ -425,7 +419,6 @@ This statement returns the record of type +MyApp.Contact+ with the id 1. If the
 
 WARNING: When +find+ is called with a record type and an id as arguments, it only looks for records of exactly this type. It will not return records which type is a subclass of the specified record type.
 
-
 h4. Finding All Records of a Certain Type
 
 To find all records of one record type, just pass it to the +find+ method:
@@ -486,7 +479,6 @@ NOTE: If the query was not yet fetched from the server, the store automatically
 
 NOTE: +SC.RecordArray+s automatically get updated by the store when you add or remove records to/from the store which match the corresponding query.
 
-
 h5. Conditions
 
 You can limit the results of a query to match certain conditions:
@@ -567,7 +559,6 @@ In this case the results are sorted in an ascending order, first by last name an
 
 NOTE: If you need a custom sorting order, you can register your own comparison operator for a specific model attribute using +SC.Query.registerComparison+. Please refer to the "documentation":http://docs.sproutcore.com/symbols/SC.Query.html#SC.Query%23registerComparison for further details.
 
-
 h5. Scoped Queries
 
 All the queries you used until now will cause the store to match all records in memory with the query's conditions. You can also build one query on top of another to construct more efficient query trees:
@@ -595,7 +586,6 @@ Remote queries (build with +SC.Query.remote+) on the other hand return a +SC.Rec
 
 WARNING: You should use local queries in almost all cases. If you use remote queries you probably know what you're doing and have already passed the scope of this guide...
 
-
 h4. Extending SproutCore's Query Language
 
 If SproutCore's built-in query operators are not sufficient for your use case, you can easily extend the query language. For example by default there are no bit-wise operators, so lets implement a +BITAND+ operator which evaluates to +true+ if the bit-wise and of the two arguments is unequal to zero:
@@ -619,7 +609,6 @@ We call +SC.Query.registerQueryExtension+ to register the new operator with the
 
 NOTE: Look at the source of SC.Query ("datastore/system/query.js") for more examples of how to implement query operators.
 
-
 h3. In-Depth Information about Record States
 
 We have covered the primary record states and the occurrence of some of the possible substates above. If you want to gain a complete understanding of what record states exist and what they mean, you will find a short description of all states below as well as complete state transition diagrams.