getting ready for submission

R/autoplot-methods.R

@@ -47,7 +47,7 @@ autoplot.constparty <- function(object, ...) {
                   )
 }
 #' @rdname autoplot.party
-#' @param plot_var Which covariable to plot against response. Defaults to second
+#' @param plot_var Which covariate to plot against response. Defaults to second
 #' column in `data` of tree.
 #' @export
 autoplot.modelparty <- function(object, plot_var = NULL, ...) {

R/geom_node_plot.R

@@ -460,7 +460,7 @@ nodeplotGrob <- function(x, y, node_gtable, width, height, just) {
 
 }
 
-#' appearantly needs to be exported
+#' apparantly needs to be exported
 #' @param x nodeplotgrob
 #' @export
 #' @md

R/ggparty.R

@@ -3,8 +3,8 @@
 #' `ggplot2` extension for objects of class `party`. Creates a `data.frame` from
 #' an object of class `party` and calls [ggplot()]
 #'
-#'  `ggparty` can be callled directly with an object of class `party`, which will
-#' convert it to a suitbale `data.frame` and pass it to a call to `ggplot` with as
+#'  `ggparty` can be called directly with an object of class `party`, which will
+#' convert it to a suitable `data.frame` and pass it to a call to `ggplot` with as
 #' the `data` argument. As usual, additional components can then be added with
 #' `+`.
 #'
@@ -28,7 +28,7 @@
 #'  of elements to be extracted from
 #'  each node of `party`  or function(s) of corresponding row of plot data and node.
 #'   In either case returned object  has to be of length 1.
-#'   If the data is supposed to be accessible by [geom_node_plot()] the resprective
+#'   If the data is supposed to be accessible by [geom_node_plot()] the respective
 #'   list entry has
 #'   to be named with the prefix `"nodedata_"` and be a function returning a list
 #'   of same length as `nodesize`.
@@ -220,7 +220,7 @@ geom_edge <- function(mapping = NULL, nudge_x = 0, nudge_y = 0, ids = NULL,
 #' @param shift Value in (0,1). Moves label along corresponding edge.
 #' @param ids Choose which splitbreaks to label by their children's ids.
 #' @param nudge_x,nudge_y Nudge label.
-#' @param splitlevels Which levels of split to plot. This may be usefull in the
+#' @param splitlevels Which levels of split to plot. This may be useful in the
 #' presence of many factor levels for one split break.
 #' @param max_length If provided **breaks_label** levels will be truncated to the specified length.
 #' @param label.size See [geom_label()].

inst/cran-comments.Rmd

@@ -1,5 +1,5 @@
 ---
-title: "Changes"
+title: "cran-comments"
 output: rmarkdown::github_document
 ---
 

vignettes/ggparty-graphic-partying.Rmd

@@ -125,7 +125,7 @@ ggparty(tr_tree, terminal_space = 0.4,
 The code used to create this plot can be found at the end of this document.
 But first things first.    
 Let's recreate a simple example already used in the [partykit vignette](https://cran.r-project.org/package=partykit/vignettes/partykit.pdf). If you
-are not familiar with the [**parykit**](https://cran.r-project.org/package=partykit) you should definitely check it out before you
+are not familiar with the [**partykit**](https://cran.r-project.org/package=partykit) you should definitely check it out before you
 work with this package.
 ```{r}
 data("WeatherPlay", package = "partykit")
@@ -191,7 +191,7 @@ Every **ggparty plot starts with a call to the eponymous `ggparty()` function wh
 * **geom_node_label()** labels the nodes with the split variable, node info or anything
 else. The shorthand versions of this geom **geom_node_splitvar()** and
 **geom_node_info()** have the correct defaults to write the split variables in
-the inner nodes resp. the info in the terminal nodes.
+the inner nodes or the info in the terminal nodes.
 * **geom_node_plot()** creates a custom ggplot at the location of the node
 
 In most cases we will probably want to draw at least edges, edge labels and node labels, so we will have to call the respective functions. The default mappings of `geom_edge()` and and `geom_edge_label()` ensure that lines between the related nodes are drawn and the corresponding split breaks are plotted at their centers.  
@@ -209,7 +209,7 @@ ggparty(py) +
 ```
 Instead of adding `geom_node_label()` we can also add the convenience versions `geom_node_splitvar()` and `geom_node_info()` which contain the correct defaults
 to plot the split variables in the inner nodes and the info in the terminal nodes.  
-Thanks to the ggplot2 mechanics we can now map different aspects of our plot to properties of the nodes. Whether that's the best choide in this case is a different question.  
+Thanks to the ggplot2 mechanics we can now map different aspects of our plot to properties of the nodes. Whether that's the best choice in this case is a different question.  
 
 ```{r, fig.width = 7}
 ggparty(py) +
@@ -290,7 +290,7 @@ gg <- ggparty(py, add_vars = list(nodedata_x_dens =
               )
 gg$data$nodedata_x_dens
 ```
-The obvious limitation of this method is, that the number of
+The obvious limitation of this method is that the number of
 observations has to be identical to the `nodesize`. In this case we achieved
 this by setting `n` of `density()` to the `nodesize`.  
 
@@ -309,7 +309,7 @@ necessary let's reiterate what `ggparty()` does and how it uses the `ggplot()`
 function. Every `ggplot()` call needs a `'data.frame'`, so as we've seen above
 `ggparty()` creates one from the `'party'` object. In this `'data.frame'` every row
 corresponds to a node of the tree.  
-Each column of this node's `data` is stored as a `'list'`in its own
+Each column of this node's `data` is stored as a `'list'` in its own
 column. This way it is not usable by `ggplot()`, since
 `ggplot()` can't handle lists inside its data. This is where `geom_node_plot()` comes
 into play and
@@ -386,7 +386,7 @@ ggparty(t2) +
 ```
 
 Setting `shared_legend` to `FALSE` draws an individual legend at each plot instead
-of one common at the bottom of the plot. This might be necessary if we use
+of one common one at the bottom of the plot. This might be necessary if we use
 multiple different `geom_node_plots()` which lead to various legends. In case we want
 to remove the legend all together (i.e. `theme(legend.position = "none")`) 
 `shared_legend` has to be set to `FALSE`.
@@ -425,11 +425,11 @@ ggparty(t2) +
 ```
 
 
-##Predictions
+## Predictions
 
 If the party object contains a model with only one predictor we can use the
 argument `predict` to choose to show a prediction line. Additional arguments for
-the `geom_line()` drawing this line can be passed via `perdict_gpar`.
+the `geom_line()` drawing this line can be passed via `predict_gpar`.
 
 So let's take a look at this `'lmtree'` containing linear models explaining `eval` with
 `beauty`.
@@ -557,7 +557,7 @@ combine the components of a `geom_node_plot()` but instead `","`.
 As we now know, each `geom_node_plot()` is basically a completely separate plot with
 its own arguments and specifications which are independent from the base plot of
 the tree (i.e. the ggparty call with edges, labels, etc.). For that reason, if
-for example, we want ro remove the legend of a `geom_node_plot()` we must not pass it
+for example, we want to remove the legend of a `geom_node_plot()` we must not pass it
 at the base level (as a component of the tree) but inside the `gglist` of the
 `geom_node_plot()`.
 
@@ -585,14 +585,14 @@ but instead pass a `'list'` of `aes()` to the argument `line_list`. The order of
 is the same as the order in which the lines will be printed. Additionally we
 have to pass a `'list'` to `line_gpar`. This list must be the same `length` as `line_list`
 and contain separately named `'lists'` of graphical parameters. If we don't want to
-change anything for a specific line, the respective '`list'` hast to be an empty
+change anything for a specific line, the respective '`list'` has to be an empty
 `'list'`.  
 
 Mapping with the `mapping` argument of `geom_node_label()` still works and
 affects all lines and the border together. The line specific graphical arguments 
 in `line_gpar` can be
 used to overwrite these `mappings`.  
-Additionally to the usual aethetic 
+Additionally to the usual aesthetic 
 parameters we would use for `ggplot`'s `geom_label()` we can pass `parse` and `alignment`
 through `line_gpar`. Parse is equivalent to the behaviour of `geom_label()` and `alignment` enables us to position the text at the left or right label border.
 
@@ -733,7 +733,7 @@ we know that the first plot now spans from 0.5 to 0.25. So we want to move the l
 second plot to 0.25, i.e. nudge it from 0.5 by -0.25.  
 
 Changing the theme from the default `theme_void` to one for which gridlines are drawn
-allows us to see the above described layout structure.
+allows us to see the layout structure described above.
 
 
 ```{r, fig.width=7, fig.asp = 1, eval = T}

vignettes/on-the-edge.Rmd

@@ -24,9 +24,9 @@ fig.width = 7
 
 Let's take a closer look at how to use `geom_edge_label()`.  
 In most cases you hopefully won't have to worry much about this geom, since the defaults should produce satisfying results.  
-But if you do want to customize anything, it might get a bit tricky. Since splits of continuous variables contain intervals we want to be able to plot inequality signs. Using Unicode to do so, proved to cause problems among other things with some pdf engines. Therefore these signs are added as parsable text.  
+But if you do want to customize anything, it might get a bit tricky. Since splits of continuous variables contain intervals we want to be able to plot inequality signs. Using Unicode to do so, proved problematic among other things with some pdf engines. Therefore these signs are added as parsable text.  
 However, this opens the door to some other potential problems. To ensure correct behaviour as per default `geom_edge_label()` parses only these signs. Therefore the additional argument `parse_all` has been added which allows to parse the whole label if set to `TRUE`. 
-First let's once more recreate the **WeatherPlay** tree. But this time we are going to arbitrary change the first 
+First let's once more recreate the **WeatherPlay** tree. But this time we are going to arbitrarily change the first 
 level of **outlook** to "beta"
 
 ```{r, echo = T, message= FALSE}
@@ -60,7 +60,7 @@ ggparty(py) +
   geom_node_info()
 ```
 
-As we can see "beta"has not been parsed, even though the argument `parse` defaults to `TRUE` and the inequality signs do have been parsed. This is due to the fact, that `geom_edge_label()` detects these signs, generated by `get_plot_data()` and deparses the rest of the label to prevent unintended parsing. In case we change the default mapping of `label` this is no longer true. 
+As we can see "beta"has not been parsed, even though the argument `parse` defaults to `TRUE` and the inequality signs have been parsed. This is due to the fact, that `geom_edge_label()` detects these signs, generated by `get_plot_data()` and deparses the rest of the label to prevent unintended parsing. In case we change the default mapping of `label` this is no longer true. 
 By setting `parse` to `FALSE` we can plot the unparsed labels:
 ```{r}
 ggparty(py) +
@@ -93,7 +93,7 @@ ggparty(py) +
   geom_node_info()
 ```
 
-Allthough the specified mapping doesn't really change anything compared to the default, it makes it harder to prevent "beta" from being parsed, since now nothing gets automatically deparsed.  
+Although the specified mapping doesn't really change anything compared to the default, it makes it harder to prevent "beta" from being parsed, since now nothing gets automatically deparsed.  
 So if we want to parse certain edges and not others, we need to call `geom_edge_label` multiple times.
 
 ```{r}