yard 0.7.5 → 0.8.0

data/benchmarks/erb_vs_erubis.rb

@@ -17,7 +17,7 @@ Benchmark.bmbm do |x|
         def erb_with(str, x) Erubis::Eruby.new(str) end
       end end end
     eof
-    
+
     rungen
   end
 
@@ -27,7 +27,7 @@ Benchmark.bmbm do |x|
         def erb_with(str, x) Erubis::FastEruby.new(str) end
       end end end
     eof
-    
+
     rungen
   end
 
@@ -37,7 +37,7 @@ Benchmark.bmbm do |x|
         def erb_with(str, x) Erubis::TinyEruby.new(str) end
       end end end
     eof
-    
+
     rungen
   end
 
@@ -47,7 +47,7 @@ Benchmark.bmbm do |x|
         def erb_with(str, x) ERB.new(str, nil) end
       end end end
     eof
-    
+
     rungen
   end
 end

data/benchmarks/generation.rb

@@ -2,20 +2,20 @@ require "benchmark"
 require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
 
 unless YARD::CodeObjects::Proxy.private_instance_methods.include?('to_obj')
-  raise "This benchmark is dependent on YARD::CodeObjects::Proxy#to_obj" 
+  raise "This benchmark is dependent on YARD::CodeObjects::Proxy#to_obj"
 end
 
 def rungen
   YARD::Registry.clear
-  YARD::CLI::Yardoc.run('--quiet', '--use-cache') 
+  YARD::CLI::Yardoc.run('--quiet', '--use-cache')
 end
 
 def redef(lock = false)
   eval <<-eof
-    class YARD::CodeObjects::Proxy; 
+    class YARD::CodeObjects::Proxy;
       def to_obj
-        @obj #{lock ? '||' : ''}= YARD::Registry.resolve(@namespace, @name) 
-      end 
+        @obj #{lock ? '||' : ''}= YARD::Registry.resolve(@namespace, @name)
+      end
     end
   eof
 end

data/benchmarks/parsing.rb

@@ -15,8 +15,8 @@ PATH_ORDER = [
 ]
 
 Benchmark.bmbm do |x|
-  x.report("parse in order") { YARD::Registry.clear; YARD.parse PATH_ORDER, [], Logger::ERROR } 
-  x.report("parse") { YARD::Registry.clear; YARD.parse 'lib/**/*.rb', [], Logger::ERROR } 
+  x.report("parse in order") { YARD::Registry.clear; YARD.parse PATH_ORDER, [], Logger::ERROR }
+  x.report("parse") { YARD::Registry.clear; YARD.parse 'lib/**/*.rb', [], Logger::ERROR }
 end
 
 =begin

data/benchmarks/registry_store_types.rb

@@ -0,0 +1,48 @@
+require 'benchmark'
+require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
+
+def parse_and_select_objects
+  YARD::Registry.load_yardoc(File.join(File.dirname(__FILE__), '..', '.yardoc'))
+  YARD::Registry.load_all
+  $paths = []
+  4.times { $paths << YARD::Registry.paths[rand(YARD::Registry.paths.size)] }
+
+  $regular_registry = {}
+  $types_registry = {}
+  YARD::Registry.all.each do |object|
+    $regular_registry[object.path] = object
+    ($types_registry[object.type] ||= {})[object.path] = object
+  end
+end
+
+def run_lookup
+  $paths.select {|path| $regular_registry[path] }
+end
+
+def run_lookup_with_types
+  $paths.select {|path| $types_registry.values.find {|list| list[path] } }
+end
+
+TIMES = 100_000
+
+parse_and_select_objects
+p $paths
+Benchmark.bmbm do |x|
+  x.report("normal") { TIMES.times { run_lookup } }
+  x.report("types")  { TIMES.times { run_lookup_with_types } }
+end
+
+__END__
+# Run on March 22 2012
+["YARD::Parser::Ruby::Legacy::RubyToken::TkUnknownChar#initialize",
+  "YARD::Parser::C::CParser#enumerator",
+  "YARD::CodeObjects::ClassObject#inherited_meths",
+  "YARD::Parser::C::Statement#source="]
+Rehearsal ----------------------------------------------
+normal       0.180000   0.000000   0.180000 (  0.182640)
+types        1.150000   0.010000   1.160000 (  1.160219)
+------------------------------------- total: 1.340000sec
+
+                 user     system      total        real
+normal       0.170000   0.000000   0.170000 (  0.165621)
+types        1.140000   0.000000   1.140000 (  1.142269)

data/bin/yard

@@ -1,4 +1,12 @@
 #!/usr/bin/env ruby
-require File.dirname(__FILE__) + '/../lib/yard'
+
+# We do all this work just to find the proper load path
+path = __FILE__
+while File.symlink?(path)
+  path = File.expand_path(File.readlink(__FILE__), File.dirname(__FILE__))
+end
+$:.unshift(File.join(File.dirname(File.expand_path(path)), '..', 'lib'))
+
+require 'yard'
 
 YARD::CLI::CommandParser.run(*ARGV)

data/bin/yardoc

@@ -1,4 +1,12 @@
 #!/usr/bin/env ruby
-require File.dirname(__FILE__) + '/../lib/yard'
+
+# We do all this work just to find the proper load path
+path = __FILE__
+while File.symlink?(path)
+  path = File.expand_path(File.readlink(__FILE__), File.dirname(__FILE__))
+end
+$:.unshift(File.join(File.dirname(File.expand_path(path)), '..', 'lib'))
+
+require 'yard'
 
 YARD::CLI::Yardoc.run(*ARGV)

data/bin/yri

@@ -1,4 +1,12 @@
 #!/usr/bin/env ruby
-require File.dirname(__FILE__) + '/../lib/yard'
 
-YARD::CLI::YRI.run(*ARGV)
+# We do all this work just to find the proper load path
+path = __FILE__
+while File.symlink?(path)
+  path = File.expand_path(File.readlink(__FILE__), File.dirname(__FILE__))
+end
+$:.unshift(File.join(File.dirname(File.expand_path(path)), '..', 'lib'))
+
+require 'yard'
+
+YARD::CLI::YRI.run(*ARGV)

data/docs/CodeObjects.md

@@ -14,9 +14,9 @@ and non-namespace objects. A namespace object refers to any object in Ruby that
 other objects defined inside of it. In the context of Ruby, this specifically means
 modules and classes (both of which are subclasses of `NamespaceObject`). These objects
 act like tree structures, maintaining a list of all of their direct children. All non
-namespace objects are simply subclasses of the Base class. The {YARD::CodeObjects::RootObject RootObject} 
+namespace objects are simply subclasses of the Base class. The {YARD::CodeObjects::RootObject RootObject}
 is a special kind of `NamespaceObject` which refers to the top level namespace in Ruby.
-Methods that accept a namespace object as a parameter should also accept the symbol 
+Methods that accept a namespace object as a parameter should also accept the symbol
 `:root` as a shortcut for the root object.
 
 The following is an overview of the classes within the `CodeObjects` namespace:
@@ -27,7 +27,7 @@ The following is an overview of the classes within the `CodeObjects` namespace:
 
 All CodeObjects are uniquely defined by their implementation of {YARD::CodeObjects::Base#path}.
 This path is used to locate or store a code object in the {YARD::Registry}. It is therefore
-essential that any Base subclass return a unique String value for #path so that the 
+essential that any Base subclass return a unique String value for #path so that the
 object may co-exist with other objects in the Registry.
 
 In practice, a path is simply the conventional Ruby representation of a class,
@@ -46,7 +46,7 @@ CodeObjects classes are coupled with the {YARD::Registry} class which keeps trac
 all instantiated code objects. This is an explicit design choice to allow objects
 to be fetched, cached, imported and exported from a centralized location. As mentioned
 above, this coupling is a result of the fact that each object is uniquely identified by
-its path, which is used to implement lookups. You can read more about the registry 
+its path, which is used to implement lookups. You can read more about the registry
 in the {YARD::Registry} class.
 
 ## Identity Map
@@ -57,7 +57,7 @@ allows developers to create a code object without checking if it already exists
 the {YARD::Registry}. The following example will only create one object:
 
     id = ClassObject.new(:root, "MyClass").object_id #=> 13352
-    ClassObject.new(:root, "MyClass").object_id #=> 13352 
+    ClassObject.new(:root, "MyClass").object_id #=> 13352
 
 ## Proxy Objects
 
@@ -69,8 +69,8 @@ attributes of a proxy are accessed, it will immediately be resolved to the objec
 at its declared path. In the case where such an object exists, it will act as
 a delegate to the object. However, if the object does not exist, a warning will
 be raised. Whenever arbitrary code objects are used, care should be taken in
-order to make sure attributes are not accessed on unresolvable proxies. An 
-unresolvable proxy will return a class name of `Proxy` and #type of `:proxy`, 
+order to make sure attributes are not accessed on unresolvable proxies. An
+unresolvable proxy will return a class name of `Proxy` and #type of `:proxy`,
 for example:
 
     P(:InvalidObject).type == :proxy  #=> true
@@ -85,8 +85,8 @@ it is possible to simply do:
 
     object = MethodObject.new(:root, "my_method")
     object[:modified_at] = Time.now
-    
-This value can now be retrieved on this object both by the hash `[]` syntax as 
+
+This value can now be retrieved on this object both by the hash `[]` syntax as
 well as like any other method:
 
     object.modified_at #=> 2009-06-03 20:08:46 -0400
@@ -111,5 +111,5 @@ following is an implementation of the path for a hypothetical `FooObject`:
     end
 
 Note that if our FooObject is a `NamespaceObject`, meaning if it can have child
-FooObjects defined inside of it, you may need to verify that the prefix is only 
+FooObjects defined inside of it, you may need to verify that the prefix is only
 applied once.

data/docs/GettingStarted.md

@@ -2,7 +2,7 @@
 
 # Getting Started with YARD
 
-There are a few ways which YARD can be of use to you or your project. This 
+There are a few ways which YARD can be of use to you or your project. This
 document will cover the most common ways to use YARD:
 
 * [Documenting Code with YARD](#docing)
@@ -25,12 +25,12 @@ manner, YARD recommends declaring your parameters, return types, etc. with
 the `@tag` syntax, which makes outputting the documentation more consistent
 and easier to read. Consider the RDoc documentation for a method to_format:
 
-    # Converts the object into textual markup given a specific `format` 
+    # Converts the object into textual markup given a specific `format`
     # (defaults to `:html`)
     #
     # == Parameters:
     # format::
-    #   A Symbol declaring the format to convert the object to. This 
+    #   A Symbol declaring the format to convert the object to. This
     #   can be `:text` or `:html`.
     #
     # == Returns:
@@ -40,7 +40,7 @@ and easier to read. Consider the RDoc documentation for a method to_format:
     def to_format(format = :html)
       # format the object
     end
-    
+
 While this may seem easy enough to read and understand, it's hard for a machine
 to properly pull this data back out of our documentation. Also we've tied our
 markup to our content, and now our documentation becomes hard to maintain if
@@ -56,7 +56,7 @@ In YARD, we would simply define our method as:
     def to_format(format = :html)
       # format the object
     end
-    
+
 Using tags we can add semantic metadata to our code without worrying about
 presentation. YARD will handle presentation for us when we decide to generate
 documentation later.
@@ -64,17 +64,17 @@ documentation later.
 ## Which Markup Format?
 
 YARD does not impose a specific markup. The above example uses standard RDoc
-markup formatting, but YARD also supports textile and markdown via the 
+markup formatting, but YARD also supports textile and markdown via the
 command-line switch or `.yardopts` file (see below). This means that you are
 free to use whatever formatting you like. This guide is actually written
-using markdown. YARD, however, does add a few important syntaxes that are 
-processed no matter which markup formatting you use, such as tag support 
+using markdown. YARD, however, does add a few important syntaxes that are
+processed no matter which markup formatting you use, such as tag support
 and inter-document linking. These syntaxes are discussed below.
 
 ## Adding Tags to Documentation
 
-The tag syntax that YARD uses is the same @tag-style syntax you may have seen 
-if you've ever coded in Java, Python, PHP, Objective-C or a myriad of other 
+The tag syntax that YARD uses is the same @tag-style syntax you may have seen
+if you've ever coded in Java, Python, PHP, Objective-C or a myriad of other
 languages. The following tag adds an author tag to your class:
 
     # @author Loren Segal
@@ -89,11 +89,11 @@ lines following a tag as part of the tag data. For example:
     #   The new method accepts the same parameters.
     def mymethod
     end
-    
+
 ### List of Tags
 
-A list of tags can be found in {file:docs/Tags.md#taglist}    
-    
+A list of tags can be found in {file:docs/Tags.md#taglist}
+
 ### Reference Tags
 
 To reduce the amount of duplication in writing documentation for repetitive
@@ -112,7 +112,7 @@ from that docstring/tag into your current object. Consider the example:
       # (see #get)
       def post(request) "hello" end
     end
-    
+
 The above `#post` method takes the docstring and all tags (`param` and `return`)
 of the `#get` method. When you generate HTML documentation, you will see this
 duplication automatically, so you don't have to manually type it out. We can
@@ -122,14 +122,14 @@ whatever we write will be appended to the docstring:
     # (see #get)
     # @note This method may modify our application state!
     def post(request) self.state += 1; "hello" end
-    
+
 Here we added another tag, but we could have also added plain text. The
 text must be appended *after* the `(see ...)` statement, preferably on
 a separate line.
 
-Note that we don't have to "refer" the whole docstring. We can also link 
-individual tags instead. Since "get" and "post" actually have different 
-descriptions, a more accurate example would be to only refer our parameter 
+Note that we don't have to "refer" the whole docstring. We can also link
+individual tags instead. Since "get" and "post" actually have different
+descriptions, a more accurate example would be to only refer our parameter
 and return tags:
 
     class MyWebServer
@@ -137,14 +137,14 @@ and return tags:
       # @param [Request] request the request object
       # @return [String] the resulting webpage
       def get(request) "hello" end
-      
+
       # Handles a POST request
       # @note This method may modify our application state!
       # @param (see #get)
       # @return (see #get)
       def post(request) self.state += 1; "hello" end
     end
-    
+
 The above copies all of the param and return tags from `#get`. Note that you
 cannot copy individual tags of a specific type with this syntax.
 
@@ -157,32 +157,33 @@ with or without a types field.
     # @return [String, nil] the contents of our object or nil
     #   if the object has not been filled with data.
     def validate; end
-    
+
     # We don't care about the "type" here:
     # @return the object
     def to_obj; end
-    
+
 The list of types is in the form `[type1, type2, ...]` and is mostly free-form,
 so we can also specify duck-types or constant values. For example:
 
     # @param [#to_s] argname any object that responds to `#to_s`
     # @param [true, false] argname only true or false
-    
-Note the the latter example can be replaced by the meta-type "Boolean", and
-numeric types can be replaced by "Number". These meta-types are by convention
+
+Note the latter example can be replaced by the meta-type "Boolean".
+Another meta-type is "void", which stands for "no meaningful value"
+and is used for return values. These meta-types are by convention
 only, but are recommended.
-    
+
 List types can be specified in the form `CollectionClass<ElementType, ...>`.
 For instance, consider the following Array that holds a set of Strings and
 Symbols:
-  
+
     # @param [Array<String, Symbol>] list the list of strings and symbols.
-    
+
 We mentioned that these type fields are "mostly" free-form. In truth, they
 are defined "by convention". To view samples of common type specifications
-and recommended conventions for writing type specifications, see 
-[http://yardoc.org/types.html](http://yardoc.org/types.html). Note that these 
-conventions may change every now and then, although we are working on a more 
+and recommended conventions for writing type specifications, see
+[http://yardoc.org/types.html](http://yardoc.org/types.html). Note that these
+conventions may change every now and then, although we are working on a more
 "formal" type specification proposal.
 
 ## Documenting DSL Methods
@@ -197,53 +198,53 @@ a typed attribute for a database model. The code might look like:
 
     class Post
       include DataMapper::Resource
-      
+
       property :title, String
     end
-    
+
 As of version 0.7.0, YARD will automatically pick up on these basic methods if
 you document them with a docstring. Therefore, simply adding some comments to
 the code will cause it to generate documentation:
 
     class Post
       include DataMapper::Resource
-      
+
       # @return [String] the title property of the post
       property :title, String
     end
 
 Note that YARD uses the first argument in the method call to determine the
 method name. In some cases, this would not be the method name, and you would
-need to declare it manually. You can do so with the `@method` tag:
+need to declare it manually. You can do so with the `@!method` directive:
 
-    # @method foo
+    # @!method foo
     create_a_foo_method
-    
-The @method tag can also accept a full method signature with parameters:
 
-    # @method foo(name, opts = {})
+The @!method directive can also accept a full method signature with parameters:
+
+    # @!method foo(name, opts = {})
     create_a_foo_method
 
 You can also set visibility and scope, or modify the method signature with
 extra tags. The following adds documentation for a private class method:
 
-    # @method foo(opts = {})
+    # @!method foo(opts = {})
     # The foo method!
-    # @scope class
-    # @visibility private
+    # @!scope class
+    # @!visibility private
     create_a_private_foo_class_method
-    
-Finally, you can tag a method as an attribute by replacing the @method
-tag with @attribute. The @attribute tag allows for the flags [r], [w], or
-[rw] to declare a readonly, writeonly, or readwrite attribute, respectively.
 
-    # @attribute [w]
+Finally, you can tag a method as an attribute by replacing the @!method
+tag with @!attribute. The @!attribute directive allows for the flags [r], [w],
+or [rw] to declare a readonly, writeonly, or readwrite attribute, respectively.
+
+    # @!attribute [w]
     # The writeonly foo attribute!
     a_writeonly_attribute :foo
-    
+
 (Note that if the name can be automatically detected, you do not need to
-specify it in the @method or @attribute tag)
-    
+specify it in the @!method or @!attribute directives)
+
 However, you will notice a few drawbacks with this basic support:
 
 1. There is a fair bit of duplication in such documentation. Specifically, we
@@ -252,7 +253,7 @@ However, you will notice a few drawbacks with this basic support:
    If we do not write a comment, it is ignored.
 
 ### Macros
-   
+
 Fortunately YARD 0.7.0 also adds macros, a powerful way to add support for
 these DSL methods on the fly without writing extra plugins. Macros allow
 you to interpolate arguments from the method call inside the docstring,
@@ -261,8 +262,8 @@ using a macro, it might look like:
 
     class Post
       include DataMapper::Resource
-  
-      # @macro dm.property
+
+      # @!macro dm.property
       # @return [$2] the $1 $0 of the post
       property :title, String
     end
@@ -275,7 +276,7 @@ section. There is also some extra benefit to using this macro, in that we
 can re-apply it to any other property in our class by simply calling on
 the macro. The following:
 
-    # @macro dm.property
+    # @!macro dm.property
     property :view_count, Integer
 
 Would be equivalent to:
@@ -292,7 +293,7 @@ by using this snippet:
     class Post
       include DataMapper::Resource
 
-      # @macro [attach] dm.property
+      # @!macro [attach] dm.property
       # @return [$2] the $1 $0 of the post
       property :title, String
       property :view_count, Integer
@@ -315,7 +316,7 @@ To link another "object" (class, method, module, etc.), use the format:
     {ObjectName#method OPTIONAL_TITLE}
     {Class::CONSTANT My constant's title}
     {#method_inside_current_namespace}
-    
+
 Without an explicit title, YARD will use the relative path to the object as
 the link name. Note that you can also use relative paths inside the object
 path to refer to an object inside the same namespace as your current docstring.
@@ -345,7 +346,7 @@ via the command-line. Consider the following examples:
 
     {file:docs/GettingStarted.md Getting Started}
     {file:mypage.html Name#anchor}
-    
+
 As shown, you can also add an optional `#anchor` if the page is an HTML link.
 
 ### Embedding Docstrings `{include:...}`
@@ -358,17 +359,17 @@ embed a docstring (minus tags) at a specific point in the text.
     # This class is cool
     # @abstract
     class Foo; end
-    
+
     # This is another class. {include:Foo} too!
     class Bar; end
-    
-The docstring for Bar becomes: 
+
+The docstring for Bar becomes:
 
     "This is another class. This class is cool too!"
 
 ### Embedding Files `{include:file:...}`
 
-You can embed the contents of files using `{include:file:path/to/file}`, 
+You can embed the contents of files using `{include:file:path/to/file}`,
 similar to the `{include:OBJECT}` tag above. If the file uses a specific markup
 type, it will be applied and embedded as marked up text. The following
 shows how the tag can be used inside of comments:
@@ -376,7 +377,7 @@ shows how the tag can be used inside of comments:
     # Here is an example of a highlighted Ruby file:
     #
     # {include:file:examples/test.rb}
-    
+
 ### Rendering Objects `{render:...}`
 
 Entire objects can also be rendered in place in documentation. This can be
@@ -384,17 +385,18 @@ used for guide-style documentation which does not document the entire source
 tree, but instead selectively renders important classes or methods. Consider
 the following documentation inside of a README file:
 
+    !!!plain
     = igLatinPay!
-    
+
     This library adds pig latin methods to the string class, allowing you
     to transform sentences into pig latin.
-    
+
     {render:String#pig_latin}
-    
+
     You can also un-pig-latin-ify a word or sentence:
-    
+
     {render:String#de_pig_latin}
-    
+
 The above would render the methods in place inside the README document,
 allowing you to summarize a small library in a single file.
 
@@ -405,8 +407,8 @@ allowing you to summarize a small library in a single file.
 ### `yard` Executable
 
 YARD ships with a single executable aptly named `yard`. In addition to
-generating standard documentation for your project, you would use this tool 
-if you wanted to: 
+generating standard documentation for your project, you would use this tool
+if you wanted to:
 
 * Document all installed gems
 * Run a local documentation server
@@ -415,7 +417,7 @@ if you wanted to:
 * Diff your documentation
 * Analyze documentation statistics.
 
-The following commands are available in YARD 0.6.x (see `yard help` for a 
+The following commands are available in YARD 0.6.x (see `yard help` for a
 full list):
 
     Usage: yard <command> [options]
@@ -444,11 +446,11 @@ you run `yardoc` from) and contains all of arguments you would otherwise pass
 to the command-line tool. For instance, if you often type:
 
     yardoc --no-private --protected app/**/*.rb - README LEGAL COPYING
-    
+
 You can place the following into your `.yardopts`:
 
     --no-private --protected app/**/*.rb - README LEGAL COPYING
-    
+
 This way, you only need to type:
 
     yardoc
@@ -456,7 +458,7 @@ This way, you only need to type:
 Any extra switches passed to the command-line now will be appended to your
 `.yardopts` options.
 
-Note that options for `yardoc` are discussed in the {file:README.md README}, 
+Note that options for `yardoc` are discussed in the {file:README.md README},
 and a full overview of the `.yardopts` file can be found in {YARD::CLI::Yardoc}.
 
 ### Documenting Extra Files
@@ -469,13 +471,13 @@ which is automatically detected by YARD if found in the root of your project
 line (or in the `.yardopts` file) by listing them after the '-' separator:
 
     yardoc lib/**/*.rb ext/**/*.c - LICENSE.txt
-  
+
 Note that the README will automatically be picked up, so you do not need to
 specify it. If you don't want to modify the default file globs, you can ignore
 the first set of arguments:
 
     yardoc - LICENSE.txt
-    
+
 Below you can read about how to customize the look of these extra files, both
 with markup and pretty titles.
 
@@ -483,23 +485,23 @@ with markup and pretty titles.
 
 You can add YARD-style `@tag` metadata to the top of any extra file if prefixed
 by a `#` hash comment. YARD allows for arbitrary meta-data, but pays special
-attention to the tags `@markup`, `@encoding`, and `@title`. Note that there 
-cannot be any whitespace before the tags. Here is an example of some tag data 
+attention to the tags `@markup`, `@encoding`, and `@title`. Note that there
+cannot be any whitespace before the tags. Here is an example of some tag data
 in a README:
 
     # @markup markdown
     # @title The Best Library in the World!
     # @author The Author Name
-    
+
     This is the best library you will ever meet. Lipsum ...
 
 The `@markup` tag allows you to specify a markup format to use for the file,
-including "markdown", "textile", "rdoc", "ruby", "text", "html", or "none" 
+including "markdown", "textile", "rdoc", "ruby", "text", "html", or "none"
 (no markup). This can be used when the markup cannot be auto-detected using
 the extension of the filename, if the file has no extension, or if you want
 to override the auto-detection.
 
-By using `@encoding` you can specify a non-standard encoding. Note that 
+By using `@encoding` you can specify a non-standard encoding. Note that
 `yardoc --charset` sets the global encoding (for all comments / files),
 so if you are using unicode across all your files, you can specify it there.
 Using the `@encoding` tag might be used to override the default global
@@ -535,7 +537,7 @@ A sample configuration file might look like:
     :autoload_plugins:
       - my_autoload_plugin
     :safe_mode: false
-    
+
 You can also view and edit these configuration options from the commandline
 using the `yard config` command. To list your configuration, use `yard config --list`.
 To view a key, use `yard config ITEM`, and to set it, use `yard config ITEM VALUE`.
@@ -544,7 +546,7 @@ To view a key, use `yard config ITEM`, and to set it, use `yard config ITEM VALU
 
 ## Extending YARD
 
-There are many ways to extend YARD to support non-standard Ruby syntax (DSLs), 
+There are many ways to extend YARD to support non-standard Ruby syntax (DSLs),
 add new meta-data tags or programmatically access the intermediate metadata
 and documentation from code. An overview of YARD's full architecture can be
 found in the {file:docs/Overview.md} document.
@@ -570,7 +572,7 @@ document covers the basics of how YARD's templating system works.
 ## Plugin Support
 
 As of 0.4, YARD will automatically load any gem named with the prefix of
-`yard-` or `yard_`. You can use this to load a custom plugin that 
+`yard-` or `yard_`. You can use this to load a custom plugin that
 [extend](#extending) YARD's functionality. A good example of this
 is the [yard-rspec][yard-rspec] plugin, which adds [RSpec][rspec] specifications
 to your documentation (`yardoc` and `yri`). You can try it out by installing