Fix typos (#142)

* Fix typos

* Rewrap paragraph to fix r rendering

* Remove extra i

Author: Bisaloo

description-file.Rmd

@@ -142,7 +142,7 @@ guidelines:
   field of `GenomicAlignments`.
   It is unusual for more than three packages to be listed as `Depends:`.
 - `Suggests:` is for packages used in vignettes, examples, and in conditional
-  code.Commonly, annotation and experiment packages (e.g., `TxDb*`) used in
+  code. Commonly, annotation and experiment packages (e.g., `TxDb*`) used in
   vignette and example code are included in this field thus avoiding a costly
   download.  In the case where an external one-off function is required for
   package code, the package availability and usage can be done via:
@@ -194,7 +194,7 @@ package type (i.e., `Software`, `AnnotationData`, `ExperimentData`, or
 The field name "biocViews" is case-sensitive and must begin with a lower-case
 'b'. Please use a single line with biocViews seperated by commas
 
-(i.e,`biocViews: GeneTarget, SingleCell`). 
+(i.e,`biocViews: GeneTarget, SingleCell`).
 
 ## `BugReports` {#description-bugreport}
 

documentation.Rmd

@@ -26,13 +26,13 @@ it is always possible to extend existing classes.
 A vignette demonstrates how to accomplish non-trivial tasks embodying the core
 functionality of your package. There are two common types of vignettes.
 
-* (Recommended) An *R markdown* vignette is similar to a *Sweave* vignette, but uses
-  [markdown](http://daringfireball.net/projects/markdown/) instead of $\LaTeX$
-  for structuring text sections and resulting in HTML output. The `r
-  BiocStyle::CRANpkg("knitr")` package can process most *Sweave* and all *R
+* (Recommended) An *R markdown* vignette is similar to a *Sweave* vignette, but
+  uses [markdown](http://daringfireball.net/projects/markdown/) instead of
+  $\LaTeX$ for structuring text sections and resulting in HTML output. The
+  `r BiocStyle::CRANpkg("knitr")` package can process most *Sweave* and all *R
   markdown* vignettes, producing pleasing output. Refer to [Writing package
-  vignettes][CRAN vigs] for technical details. See the `r
-  BiocStyle::Biocpkg("BiocStyle")` package for a convenient way to use common
+  vignettes][CRAN vigs] for technical details. See the
+  `r BiocStyle::Biocpkg("BiocStyle")` package for a convenient way to use common
   macros and a standard _Bioconductor_ style vignette.
 
 * A *Sweave* vignette is an `.Rnw` file that contains $\LaTeX$ and chunks of <i
@@ -103,7 +103,7 @@ Add an "Installation" section that show to users how to download and load the
 package from Bioconductor.
 
 These instructions and any installations instructions should be in an
-`eval=FALSE` code chunk. No where in the code (<i class="fab fa-r-project"></i>
+`eval=FALSE` code chunk. Nowhere in the code (<i class="fab fa-r-project"></i>
 code, man pages, vignettes, Rmd files) should someone try to install or download
 system dependencies, applications, packages, etc. Developers can provide
 instructions to follow in unevaluated code chunks, and should assume all

non-software-packages.Rmd

@@ -58,7 +58,7 @@ expected the majority of vignette code chunks are evaluated.
 * Write a package with the same name as the workflow. The workflow vignette
  written in Markdown, using the [rmarkdown][] package should be included in the
  vignette directory. You may include more than one vignette but please use
- useful identifying names. 
+ useful identifying names.
 
 * The package does not need man/ or R/ directories nor a data/ directory as
  ideally workflows make use of existing data in a Bioconductor repository or on
@@ -72,7 +72,7 @@ expected the majority of vignette code chunks are evaluated.
 
 * Submit the package to the [GitHub submission tracker][tracker] for a formal
   review. Please also indicate in the tracker issue that this package is a
-  workflow.  
+  workflow.
 
 * Workflows are git version controlled. Once the package is accepted it will be
   added to our git repository at [email protected] and instructions will
@@ -91,13 +91,13 @@ expected the majority of vignette code chunks are evaluated.
 		BiocStyle::html_document
 	```
 
-* The following should also be include
+* The following should also be included
 
       - author affiliations
       - a date representing when the workflow vignette has been modified
 
 * The first section should have some versioning information. The  R version,
-  Bioconductor version, and package version should be visible. 
+  Bioconductor version, and package version should be visible.
   The following is an example of how this could be achieved:
 
 <pre>
@@ -123,14 +123,14 @@ The following is taken as an example header from the variants workflow package:
     <code>
 &ndash; &ndash; &ndash;
 title&#58; Annotating Genomic Variants
-author&#58; 
+author&#58;
 &ndash;name&#58; Valerie Obenchain
   affiliation&#58; Fred Hutchinson Cancer Research Center, 1100 Fairview Ave. N., P.O. Box 19024, Seattle, WA, USA 98109&ndash;1024
 date&#58; 11 April 2018
 vignette&#58; &#62;
   &#37;&#92;VignetteIndexEntry&#123;Annotating Genomic Variants&#125;
   &#37;&#92;VignetteEngine&#123;knitr&#58;&#58;rmarkdown&#125;
-output&#58; 
+output&#58;
     BiocStyle&#58;&#58;html&#95;document
 &ndash; &ndash; &ndash;
 

package-submission.Rmd

@@ -168,7 +168,7 @@ package maintenance responsibilities. Package authors are expected to:
   DESCRIPTION file. This field indicates a particular web page for submitting
   bug reports and questions.
 
-* Ensure the maintainer email in the DESCRIPTIONS stays accurate and
+* Ensure the maintainer email in the DESCRIPTION stays accurate and
   reachable. The maintainer email in the DESCRIPTION is the definitive contact
   _Bioconductor_ will use. It is important to keep this email up-to-date to
   ensure we can contact you if your package is failing or to notify you of any
@@ -257,7 +257,7 @@ use of existing data in a Bioconductor package. See development section on
 * The moderator will add your package as a repository to the
   git.bioconductor.org git server, copy the SSH keys from your github
   account to the [BiocCredentials application][] application and the issue labelled
-  `pre-review`.  
+  `pre-review`.
 
   ALL CHANGES TO YOUR PACKAGE must be pushed to the
   git.bioconductor.org repository created in this step. See the [New package

r-code.Rmd

@@ -1,7 +1,7 @@
 # R code {#r-code}
 
 Everyone has their own coding style and formats. There are however some best
-practice guidelines that [_Bioconductor_ reviewers][reviewer-list] will look for. 
+practice guidelines that [_Bioconductor_ reviewers][reviewer-list] will look for.
 
 <i class="fab fa-r-project"></i> can be a robust, fast and efficient programming
 language but often some coding practices result in less than ideal use of
@@ -31,7 +31,7 @@ Make use of appropriate existing packages (e.g.,
 `r BiocStyle::Biocpkg("GenomicRanges")`) and classes (e.g.,
 `r BiocStyle::Biocpkg("SummarizedExperiment")`,
 `r BiocStyle::Biocpkg("Biobase")`::AnnotatedDataFrame,
-`r BiocStyle::Biocpkg("GenomicRanges")`:;GRanges,
+`r BiocStyle::Biocpkg("GenomicRanges")`::GRanges,
 `r BiocStyle::Biocpkg("Biostrings")`::DNAStringSet) to avoid duplication of functionality
 available in other [_Bioconductor_][] packages. See
 also [Common Bioconductor Methods and Classes][bioc-common].
@@ -75,7 +75,7 @@ we recommend to use standard file format classes inheriting from
 ### Naming of packages, functions, and classes {#naming-functions}
 
 See section on [package naming](#package-name). The concepts there should also
-apply to function names, class names, etc. 
+apply to function names, class names, etc.
 
 Avoid names that:
 
@@ -111,7 +111,7 @@ separate packages.
 
 Remember to **re-use** [common _Bioconductor_ methods and classes][bioc-common]
 before implementing new representations. This encourages
-interoperability and simplifies your own package development. 
+interoperability and simplifies your own package development.
 
 #### Class Names {#class-names}
 
@@ -123,7 +123,7 @@ _Bioconductor_ prefers the use of S4 classes over S3 class. Please use the S4
 representation for designing new classes. Again, we can not emphasize enough to
 reuse existing class structure if at all possible. If an existing class
 structure is not sufficient, it is also encouraged to look at extending or
-containing an [existing _Bioconductor_ class](#commonclass). 
+containing an [existing _Bioconductor_ class](#commonclass).
 
 If your data requires a new representation or function, carefully
 design an S4 class or generic so that other package developers with
@@ -168,7 +168,7 @@ installation.
 
 
 ### Function development {#function-development}
- 
+
 #### Functions Names {#rcode-function-names}
 
 Function names should follow the following conventions:
@@ -195,7 +195,7 @@ helper functions.
 * Nesting functions should be avoiding. It unnecessarily increases the main
   function length and makes the main function harder to read. Helper functions
   and internal functions should avoid being nested and include at the end of the
-  file or as a seperate file (e.g. internal.R, helpers.R, utils.R)  
+  file or as a seperate file (e.g. internal.R, helpers.R, utils.R)
 
 #### Function arguments {#function-arguments}
 
@@ -233,8 +233,8 @@ already there.
 
 All system and package dependencies should be the latest publically available
 version. All package dependencies must actively be on CRAN or
-Bioconductor. Bioconductor will not recognize Remotes in Description and will
-not install a lower version of a package or dependency.  
+Bioconductor. Bioconductor will not recognize Remotes in DESCRIPTION and will
+not install a lower version of a package or dependency.
 
 ####  Namespaces {#rcode-namespaces}
 
@@ -387,7 +387,7 @@ from a variable.
 * `warning()` communicates unusual situations handled by your code.
 * `stop()` indicates an error condition.
 * `cat()` or `print()` are used only when displaying an object to the user in a `show` method.
-  
+
 #### Graphic Device
 
 Use `dev.new()` to start a graphics drive if necessary. Avoid using `x11()`
@@ -433,7 +433,7 @@ coding practices can be very unfortunate. Here are some suggestions.
 ### Reuse Existing Functionality and Classes
 
 Emphasized again for good measure!  Reuse existing import/export methods,
-functionality, and classes whenever possible. 
+functionality, and classes whenever possible.
 
 ### Vectorize