Documentation fixes

lib/Kelp/Manual.pod

@@ -62,21 +62,6 @@ omitted adding certain components. This is where Kelp gets to shine. It provides
 a layer on top of Plack and puts everything together into a complete web
 framework.
 
-=head2 New Kelp versions and backward compatibility
-
-Versions 2 and 2.10 of Kelp introduced some breaking changes, especially when
-it comes to how requests are decoded and how the errors are rendered. If you
-are affected and don't want to modify your code, you are welcome to use a fixed
-version C<2.00> (with less incompatibilities) or C<1.07> (without
-incompatibilities). You will be missing on a lot of improvements though - most
-of these changes were bugfixes or security fixes.
-
-Kelp values backward compatibility, but at the same time it will not be
-hesitant to fix bugs, security issues or major inconveniences where it sees
-necessary. From 2.10 forward, non-bugfix breaking changes will only be
-introduced after a 6-month deprecation period. Changelog will list them under
-C<[Deprecations]> section.
-
 =head1 CREATING A NEW WEB APP
 
 =head2 Quick development using Kelp::Less
@@ -171,7 +156,7 @@ This is where the C<Template> module will look for template files.
 
 =item B</log>
 
-This is where the C<Logger> module will create C<error.log>, C<debug.log> and
+This is where the C<Logger> module will create C<error.log> and
 any other log files that were defined in the configuration.
 
 =item B</t>
@@ -725,10 +710,9 @@ that, it may come in handy when debugging.
 
 =head3 Creating your own module
 
-Each new module must be a
-subclass of the C<Kelp::Module> class. Modules' job is to initialize and
-register new methods into the web application class. Here is a simple module
-which initializes an extremely simple cache:
+Each new module must be a subclass of the C<Kelp::Module> class. Modules' job
+is to initialize and register new methods into the web application class. Here
+is a module which initializes an extremely simple cache:
 
     package Kelp::Module::ExampleCache;
 
@@ -877,6 +861,21 @@ Run the rest as usual, using C<prove>:
 
 Take a look at the L<Kelp::Test> for details and more examples.
 
+=head2 Future compatibility
+
+Versions C<2.00> and C<2.10> of Kelp introduced some breaking changes,
+especially when it comes to how requests are decoded and how the errors are
+rendered. If you are affected and don't want to modify your code, you are
+welcome to use a fixed version C<2.00> (with less incompatibilities) or C<1.07>
+(without incompatibilities). You will be missing on a lot of improvements
+though - most of these changes were bugfixes or security fixes.
+
+Kelp values backward compatibility, but at the same time it will not be
+hesitant to fix bugs, security issues or major inconveniences where it sees
+necessary. From C<2.10> forward, non-bugfix breaking changes will only be
+introduced after a 6-month deprecation period. Changelog will list
+them under C<[Deprecations]> section.
+
 =head2 Other documentation
 
 You may want to take a look at our L<Kelp::Manual::Cookbook> for common

lib/Kelp/Manual/Controllers.pod

@@ -23,7 +23,7 @@ be subclasses of L<Kelp>.
 
 Reblessing will happen after request is matched to a route. Route handler has
 to be specified as class and method string, and class must be a subclass of class
-configured for C<Kelp::Routes/base>. C<Kelp::Routes/rebless> must albo be
+configured for L<Kelp::Routes/base>. L<Kelp::Routes/rebless> must albo be
 enabled for that to occur.
 
 The default value of C<base> field is the application class, so your
@@ -117,11 +117,11 @@ You no longer have to prefix destinations with the base controller class name.
 =head1 CAVEATS
 
 There are some controller gotchas which come from a fact that they are not
-contructed like a regular object:
+constructed like a regular object:
 
 =head2 Controller's constructor is never called
 
-Controllers are also never actually constructed, but instead the main app
+Controllers are never actually constructed, but instead the main app
 object is cloned and reblessed into the correct class. Don't expect your
 override of C<new> or C<build> to work.
 

lib/Kelp/Manual/Cookbook.pod

@@ -267,7 +267,7 @@ easy to use the same charset in response as the one you got in request:
         return 'et voilà!';
     });
 
-Note that request charset is only getting used if the C<Content-Type> of the
+Note that request charset is only actually used if the C<Content-Type> of the
 request is either C<text/*> or C<application/*>.
 
 =head1 SEE ALSO

lib/Kelp/Module/Config.pm

@@ -416,7 +416,7 @@ This module registers the following methods into the underlying app:
 
 =head2 config
 
-A wrapper for the C</get> method.
+A wrapper for the L</get> method.
 
     # Somewhere in the app
     my $pos = $self->config('row.col.position');
@@ -433,7 +433,7 @@ A reference to the entire configuration hash.
 
     my $pos = $self->config_hash->{row}->{col}->{position};
 
-Using this or C<config> is entirely up to the application developer.
+Using this or L</config> is entirely up to the application developer.
 
 =head3 _cfg
 
@@ -538,13 +538,17 @@ response (unless charset is set manually for a response). Any encoding
 supported by L<Encode> is fine. It should probably stay as default C<UTF-8>
 unless you're doing something non-standard.
 
+Can be set to undef to disable response encoding.
+
 =head2 request_charset
 
 Default incoming charset, which will be used to decode requests (unless the
 request contains its own). It will always be used to decode URI elements of the
-request. It is strongly recommended this stays as default C<UTF-8>, but can
+request. It is B<strongly recommended> this stays as default C<UTF-8>, but can
 also be set to other one-byte encodings if needed.
 
+Can be set to undef to disable request decoding entirely.
+
 =head2 app_url
 
 Abosulte URL under which the application is available.

lib/Kelp/Module/Encoder.pm

@@ -88,7 +88,7 @@ Kelp::Module::Encoder - Base class for encoder modules
 =head1 DESCRIPTION
 
 This is a base class for encoders which want to be compilant with the new
-L<Kelp/get_encoder> method. L</Kelp::Module::JSON> is one of such modules.
+L<Kelp/get_encoder> method. L<Kelp::Module::JSON> is one of such modules.
 
 This allows to have all encoders in one easy to reach spot rather than a bunch
 of unrelated methods attached to the main class. It also allows to configure a