more markdown changes

see previous commit message & description

README.md

@@ -1,10 +1,9 @@
-/*
 
-									#* * * * * * * * * * * * 
+									* * * * * * * * * * * * 
 
-									#RESKNIFE  READ-ME
+									RESKNIFE  READ-ME
 
-									#* * * * * * * * * * * * 
+									* * * * * * * * * * * * 
 												
 
 				Last updated by someone official: 9 November 2003 (i.e. a really long time ago)
@@ -36,7 +35,9 @@ BUILDING A PLUGIN
 If you want to create a Cocoa plugin for ResKnife, use the "ICONEditor" project as the basis until the SDK is available. It's a simple, standalone project. You can install it in three places:
 
 -> In ResKnife itself by selecting it, choosing "Information" and there clicking the "Add" button in the "plugins" section
+
 -> In ~/Library/Application Support/ResKnife/Plugins/ for one user account.
+
 -> In /Library/Application Support/ResKnife/Plugins/ for the entire machine.
 
 If you want to create a plugin for the Carbon version of ResKnife, take a look at the Hex Editor try to derive something from that. Editors for the Classic version 
@@ -57,7 +58,9 @@ AUTHORS
 -------
 
 ResKnife was written by Nicholas Shanks http://web.nickshanks.com/ with additional changes and some editors supplied by M. Uli Kusterer http://www.zathras.de/
+
 Other contributors include (in alphabetical order): Thomas Castiglione, Philippe Devallois, Mike Margolis, Lane Roathe and Jeffrey Seibert.
+
 There is a web site for ResKnife at http://resknife.sourceforge.net/
 
 
@@ -72,23 +75,36 @@ Notes on commenting/documenting for the ResKnife project:
 ResKnife methods, functions, headers, classes, ivars and practically anything else is commented using the format specified by HeaderDoc (a C-based equivalent to JavaDoc), although with ResKnife-specific modifications (NB: although I've yet to modify HeaderDoc to read these new parameters, they should still be used for the time being). The general format is to use the standard C block-commenting mechanism, with the addition of an exclamation mark immediately after the open comment marker. Following this are one or more lines beginning with an at sign, a keyword, arguments if any, and finally a string value. For source code consistency, I (Nicholas) am suggesting the following when documenting an object.
 
 1) All HeaderDoc comments immediately precede the object to which they pertain.
+
 2) HeaderDoc comments documenting a method or function must follow the following order (for consistency & readability), where an ellipsis indicates the line above can be repeated multiple times:
 		
-	`@method` or `@function`
-	`@abstract`
-	`@author`
-	`@created`
-	`@updated`		[significant changes that other developers should be aware of; ordered reverse chronological, i.e. most recent at the top]
-	 ...
-	`@pending`		[higher priority TODO items should be above lower priority ones]
-	 ...
-	`@description`
-	`@param`			[listed in order taken by method/function]
-	 ...
+`@method` or `@function`
+
+`@abstract`
+
+`@author`
+
+`@created`
+
+`@updated`		[significant changes that other developers should be aware of; ordered reverse chronological, i.e. most recent at the top]
+
+ ...
+
+`@pending`		[higher priority TODO items should be above lower priority ones]
+
+ ...
+
+`@description`
+
+`@param`			[listed in order taken by method/function]
+
+ ...
 	
 3) The pertinent keywords or their equivalents in the above item should retain the specified order wherever reasonably applicable (e.g. for `@class` and `@protocol` comments)
+
 4) The value for the `@created` keyword should take the following form: `YYYY-MM-DD`
+
 5) The value for the `@updated` keyword should take the following form: `YYYY-MM-DD Author: Description` where "Author" is your initials or Sourceforge user name (or Github user name).
 	
-	Due to really poor maintenance on my part, very few methods have `@updated` comments. Sorry :-(
-*/
+Due to really poor maintenance on my part, very few methods have `@updated` comments. Sorry :-(
+