minor adjustments

symfony · weaverryan · Nov 5, 2014 · Sep 17, 2014 · Sep 30, 2014 · Sep 30, 2014
commit edb0ff972b666580f35b13542fc1a1de7ac9e000
diff --git a/components/var_dumper/advanced.rst b/components/var_dumper/advanced.rst
@@ -32,11 +32,11 @@ Before dumping it, you can further limit the resulting
 :method:`Symfony\\Component\\VarDumper\\Cloner\\Data::getLimitedClone`
 method:
 
-- the first ``$maxDepth`` argument allows limiting dumps in the depth dimension,
-- the second ``$maxItemsPerDepth`` limits the number of items per depth level,
-- and the last ``$useRefHandles`` defaults to ``true`` but allows removing internal
+* the first ``$maxDepth`` argument allows limiting dumps in the depth dimension,
+* the second ``$maxItemsPerDepth`` limits the number of items per depth level,
+* and the last ``$useRefHandles`` defaults to ``true`` but allows removing internal
   objects' handles for sparser output,
-- but unlike the previous limits on cloners that remove data on purpose, these
+* but unlike the previous limits on cloners that remove data on purpose, these
   limits can be changed back and forth before dumping since they do not affect
   the intermediate representation internally.
 
@@ -156,11 +156,11 @@ They are called in registration order.
 Casters are responsible for returning the properties of the object or resource
 being cloned in an array. They are callables that accept four arguments:
 
-- the object or resource being casted,
-- an array modelled for objects after PHP's native ``(array)`` cast operator,
-- a :class:`Symfony\\Component\\VarDumper\\Cloner\\Stub` object
+* the object or resource being casted,
+* an array modelled for objects after PHP's native ``(array)`` cast operator,
+* a :class:`Symfony\\Component\\VarDumper\\Cloner\\Stub` object
   representing the main properties of the object (class, type, etc.),
-- true/false when the caster is called nested is a structure or not.
+* true/false when the caster is called nested is a structure or not.
 
 Here is a simple caster not doing anything::
 

diff --git a/components/var_dumper/introduction.rst b/components/var_dumper/introduction.rst
@@ -17,48 +17,47 @@ Installation
 
 You can install the component in 2 different ways:
 
-- :doc:`Install it via Composer </components/using_components>` (``symfony/var-dumper`` on `Packagist`_);
-- Use the official Git repository (https://github.com/symfony/var-dumper).
+* :doc:`Install it via Composer </components/using_components>` (``symfony/var-dumper`` on `Packagist`_);
+* Use the official Git repository (https://github.com/symfony/var-dumper).
 
-The dump() function
+The dump() Function
 -------------------
 
 The VarDumper component creates a global ``dump()`` function that you can
 use instead of e.g. :phpfunction:`var_dump`. By using it, you'll gain:
 
-- per object and resource types specialized view to e.g. filter out
+* Per object and resource types specialized view to e.g. filter out
   Doctrine internals while dumping a single proxy entity, or get more
-  insight on opened files with :phpfunction:`stream_get_meta_data()`.
-- configurable output formats: HTML or colored command line output.
-- ability to dump internal references, either soft ones (objects or
+  insight on opened files with :phpfunction:`stream_get_meta_data()`;
+* Configurable output formats: HTML or colored command line output;
+* Ability to dump internal references, either soft ones (objects or
   resources) or hard ones (``=&`` on arrays or objects properties).
   Repeated occurrences of the same object/array/resource won't appear
   again and again anymore. Moreover, you'll be able to inspect the
-  reference structure of your data.
-- ability to operate in the context of an output buffering handler.
+  reference structure of your data;
+* Ability to operate in the context of an output buffering handler.
 
-``dump()`` is just a thin wrapper for
-:method:`VarDumper::dump() <Symfony\\Component\\VarDumper\\VarDumper::dump>`
-so can you also use it directly.
+``dump()`` is just a thin wrapper and more convenient way to call
+:method:`VarDumper::dump() <Symfony\\Component\\VarDumper\\VarDumper::dump>`.
 You can change the behavior of this function by calling
 :method:`VarDumper::setHandler($callable) <Symfony\\Component\\VarDumper\\VarDumper::setHandler>`:
 calls to ``dump()`` will then be forwarded to ``$callable``.
 
-Output format and destination
+Output Format and Destination
 -----------------------------
 
 If you read the `advanced documentation <advanced>`, you'll learn how to
 change the format or redirect the output to wherever you want.
 
 By default, these are selected based on your current PHP SAPI:
 
-- on the command line (CLI SAPI), the output is written on ``STDERR``. This
+* On the command line (CLI SAPI), the output is written on ``STDERR``. This
   can be surprising to some because this bypasses PHP's output buffering
   mechanism. On the other hand, it give the possibility to easily split
-  dumps from regular output by using pipe redirection.
-- on other SAPIs, dumps are written as HTML on the regular output.
+  dumps from regular output by using pipe redirection;
+* On other SAPIs, dumps are written as HTML on the regular output.
 
-DebugBundle and Twig integration
+DebugBundle and Twig Integration
 --------------------------------
 
 The ``DebugBundle`` allows greater integration of the component into the
@@ -76,17 +75,18 @@ or a fatal error occurred, then dumps are written on the regular output.
 In a Twig template, two constructs are available for dumping a variable.
 Choosing between both is mostly a matter of personal taste, still:
 
-- ``{% dump foo.bar %}`` is the way to go when the original template output
+* ``{% dump foo.bar %}`` is the way to go when the original template output
   shall not be modified: variables are not dumped inline, but in the web
-  debug toolbar.
-- on the contrary, ``{{ dump(foo.bar) }}`` dumps inline and thus may or not
+  debug toolbar;
+* on the contrary, ``{{ dump(foo.bar) }}`` dumps inline and thus may or not
   be suited to your use case (e.g. you shouldn't use it in an HTML
   attribute or a ``<script>`` tag).
 
 By default for nested variables, dumps are limited to a subset of their
 original value. You can configure the limits in terms of:
-- maximum number of items to dump,
-- maximum string length before truncation.
+
+* maximum number of items to dump,
+* maximum string length before truncation.
 
 .. configuration-block::
 
@@ -106,7 +106,7 @@ original value. You can configure the limits in terms of:
             <config max-items="250" max-string-length="-1" />
         </container>
 
-Reading a dump
+Reading a Dump
 --------------
 
 For simple variables, reading the output should be straightforward::