Reindent to two spaces per level. Remove vi: directives that haven't worked right in years (ubuntu broke its' vim implementation). Remove trailing spaces. Add/remove blank lines. Re-wordwrap in places. Update documentation with new coding style.

The actual code should be the same afterward, this is just cosmetic refactoring.

2 files changed, 5 insertions, 8 deletions

diff --git a/www/code.html b/www/code.html
index 4f0843dc..75483564 100644
--- a/www/code.html
+++ b/www/code.html
@@ -13,11 +13,8 @@ This helps code auditing and thus reduces bugs. That said, sometimes being
 more explicit is preferable to being clever enough to outsmart yourself:
 don't be so terse your code is unreadable.</p>
 
-<p>Toybox source is formatted to be read with 4-space tab stops.  Each file
-starts with a special comment telling vi to set the tab stop to 4.  Note that
-one of the bugs in Ubuntu 7.10 broke vi's ability to parse these comments; you
-must either rebuild vim from source, or go ":ts=4" yourself each time you load
-the file.</p>
+<p>Toybox source uses two spaces per indentation level, and wraps at 80
+columns.</p>
 
 <p>Gotos are allowed for error handling, and for breaking out of
 nested loops.  In general, a goto should only jump forward (not back), and
@@ -31,7 +28,7 @@ to spot as overrides to the normal flow of control, which they are.</p>
 <p>Toybox is configured using the Kconfig language pioneered by the Linux
 kernel, and adopted by many other projects (uClibc, OpenEmbedded, etc).
 This generates a ".config" file containing the selected options, which
-controls which features to enable when building toybox.</p>
+controls which features are included when compiling toybox.</p>
 
 <p>Each configuration option has a default value. The defaults indicate the
 "maximum sane configuration", I.E. if the feature defaults to "n" then it
diff --git a/www/design.html b/www/design.html
index 5adae0a9..ce5fc55b 100644
--- a/www/design.html
+++ b/www/design.html
@@ -71,7 +71,7 @@ but it's just as true that a loop which stays in L1 cache is many times faster
 than a loop that has to wait for a DRAM fetch on each iteration.  Don't worry
 about whether "&" is faster than "%" until your executable loop stays in L1
 cache and the data access is fetching cache lines intelligently.  (To
-understand DRAM, L1, and L2 cache, read Hannibal's marvelous ram guid at Ars
+understand DRAM, L1, and L2 cache, read Hannibal's marvelous ram guide at Ars
 Technica:
 <a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part1-2.html>part one</a>,
 <a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part2-1.html>part two</a>,
@@ -277,7 +277,7 @@ messages produced by perror_exit() and friends can be expected to be
 localized by libc. Our error functions also prepend the command name,
 which non-english speakers can presumably recognize already.</p>
 
-<p>An enventual goal is UTF-8 support, although it isn't a priority for the
+<p>An enventual goal is <a href=http://yarchive.net/comp/linux/utf8.html>UTF-8</a> support, although it isn't a priority for the
 first pass of each command. (All commands should at least be 8-bit clean.)</p>
 
 <p>Locale support isn't currently a goal; that's a presentation layer issue,