docs link fixes

docs/color-mapping.ipynb

@@ -6,7 +6,7 @@
    "metadata": {},
    "source": [
     "# Color-mapping\n",
-    "Color mapping is a convenient method and syntax that allows for transforming/projecting raw data values into a range of valid color values drawn either from a discrete or continuous colormap. This is especially useful for visualizing a range of data values on the edges or nodes of a tree. (See [Range-Mapping](/range-mapping/) for a similar implementation to project continuous data to a new continuous range of values.)"
+    "Color mapping is a convenient method and syntax that allows for transforming/projecting raw data values into a range of valid color values drawn either from a discrete or continuous colormap. This is especially useful for visualizing a range of data values on the edges or nodes of a tree. (See [Range-Mapping](/toytree/range-mapping/) for a similar implementation to project continuous data to a new continuous range of values.)"
    ]
   },
   {

docs/data.ipynb

@@ -121,7 +121,7 @@
    "metadata": {},
    "source": [
     "## Features\n",
-    "In `toytree` terminology a \"feature\" refers the name of trait for which data is stored to nodes in a tree. For example, each `ToyTree` has several data features by default, such as `name`, `dist`, and `support`. You can create and store data under any arbitrary feature name (except for a few disallowed names and characters), and, in fact when you load a tree from a newick, NHX, or NEXUS formatted data file created by a phylogenetic tree inference program, it will often contain additional metadata that will be loaded as features. Several examples of this are shown in [tree parsing documentation](/parse_trees/#nhx-format). A `ToyTree` contains a dynamic propery `.features` containing all feature names currently assigned to that tree. (This includes any feature that is assigned to at least one Node in the tree, but it does not need to be assigned to every Node in the tree.)"
+    "In `toytree` terminology a \"feature\" refers the name of trait for which data is stored to nodes in a tree. For example, each `ToyTree` has several data features by default, such as `name`, `dist`, and `support`. You can create and store data under any arbitrary feature name (except for a few disallowed names and characters), and, in fact when you load a tree from a newick, NHX, or NEXUS formatted data file created by a phylogenetic tree inference program, it will often contain additional metadata that will be loaded as features. Several examples of this are shown in [tree parsing documentation](/toytree/parse_trees/#nhx-format). A `ToyTree` contains a dynamic propery `.features` containing all feature names currently assigned to that tree. (This includes any feature that is assigned to at least one Node in the tree, but it does not need to be assigned to every Node in the tree.)"
    ]
   },
   {
@@ -152,7 +152,7 @@
    "metadata": {},
    "source": [
     "### Data as Node attributes\n",
-    "When storing data to a `ToyTree` it is actually stored to individual `Node` objects as [Node attributes](/node/#attributes). This is demonstrated below where data is assigned to a feature named \"Z\" for two Nodes in the tree. Setting and retrieving data directly from Nodes as attributes like this is the fastest way to set/get data, and is thus especially useful for developers. However, for general `toytree` usage, we recommend using the helper functions `set_node_data` and `get_node_data` to set and retrieve data as they provide a number of benefits, especially in terms of dealing with missing values, checking data types, and ordering data values."
+    "When storing data to a `ToyTree` it is actually stored to individual `Node` objects as [Node attributes](/toytree/node/#attributes). This is demonstrated below where data is assigned to a feature named \"Z\" for two Nodes in the tree. Setting and retrieving data directly from Nodes as attributes like this is the fastest way to set/get data, and is thus especially useful for developers. However, for general `toytree` usage, we recommend using the helper functions `set_node_data` and `get_node_data` to set and retrieve data as they provide a number of benefits, especially in terms of dealing with missing values, checking data types, and ordering data values."
    ]
   },
   {
@@ -344,7 +344,7 @@
    "metadata": {},
    "source": [
     "### Setting data by dict\n",
-    "The simplest way to enter specific data values is by using a dictionary. The keys of the dictionary can correspond to any valid [Node Query](/query) to select one or more Nodes, and the corresponding value will be assigned to these Nodes. Notably, you can enter a dict selecting only a few Nodes and a feature will be assigned to those Nodes, and not to any of the other Nodes not entered in the dict. If you want to assign a default value to all other nodes you can do so using  `default` argument. Finally, the argument `inherit` can be used to also assign a value to all descendants of a selected Node. Examples of each of these is shown below."
+    "The simplest way to enter specific data values is by using a dictionary. The keys of the dictionary can correspond to any valid [Node Query](/toytree/query) to select one or more Nodes, and the corresponding value will be assigned to these Nodes. Notably, you can enter a dict selecting only a few Nodes and a feature will be assigned to those Nodes, and not to any of the other Nodes not entered in the dict. If you want to assign a default value to all other nodes you can do so using  `default` argument. Finally, the argument `inherit` can be used to also assign a value to all descendants of a selected Node. Examples of each of these is shown below."
    ]
   },
   {
@@ -1070,7 +1070,7 @@
    "id": "4b0ea57b-bad2-4530-97ca-7f9a339d31d6",
    "metadata": {},
    "source": [
-    "**(3)** The third method uses toytree's \"tuple syntax\" that is used for range and color mapping (See [*range-mapping*](/range-mapping) and [*color-mapping*](/color-mapping)). For colors, you can enter (feature name, colormap, min-value, max-value, nan-value), to map any feature to any range of colors in a colormap. Only the first argument is required, with additional args providing style options, as shown below."
+    "**(3)** The third method uses toytree's \"tuple syntax\" that is used for range and color mapping (See [*range-mapping*](/toytree/range-mapping) and [*color-mapping*](/toytree/color-mapping)). For colors, you can enter (feature name, colormap, min-value, max-value, nan-value), to map any feature to any range of colors in a colormap. Only the first argument is required, with additional args providing style options, as shown below."
    ]
   },
   {
@@ -1151,7 +1151,7 @@
    "metadata": {},
    "source": [
     "## Node vs Edge features\n",
-    "Some data stored to a tree are intended to represent information about the edges (splits) in a tree, rather than information about the nodes. This is important as these types of data must be treated differently when doing things like re-rooting a tree, and in some cases, for visualization. (See the [rooting](/rooting) tutorial for an example of how this is automatically handled in `toytree`.) Any feature can be optionally plotted as a marker and/or label on edges of a tree rather than on nodes. This can be done in a simple way within the `.draw` function by using the argument `node_as_edge_data=True`, or, it can be done with many more options by using functions in the `toytree.annotate` subpackage.\n",
+    "Some data stored to a tree are intended to represent information about the edges (splits) in a tree, rather than information about the nodes. This is important as these types of data must be treated differently when doing things like re-rooting a tree, and in some cases, for visualization. (See the [rooting](/toytree/rooting) tutorial for an example of how this is automatically handled in `toytree`.) Any feature can be optionally plotted as a marker and/or label on edges of a tree rather than on nodes. This can be done in a simple way within the `.draw` function by using the argument `node_as_edge_data=True`, or, it can be done with many more options by using functions in the `toytree.annotate` subpackage.\n",
     "\n",
     "Examples of plotted edge features are shown below. These have a few key features in visualization: (1) values are plotted on the midpoint of edges; (2) No value is shown for the root edge, since it does not represent a true split in the tree; and (3) only one of the two edges descended from the root show a value, since these are actually the same edge, but on which the root node has been placed. As an example of this last point, a value such as a support score, or edge length, is a feature of this entire edge. Thus, the value is the same whether the tree is rooted or unrooted, as shown below."
    ]

docs/drawing-basics.ipynb

@@ -725,7 +725,7 @@
    "source": [
     "## Drawing nodes\n",
     "\n",
-    "Plotting node values on a tree is a useful way of representing additional information about trees. See the [Data/Features](/data) section for details on extracting data from tree objects to plot on nodes. Here we will focus on options available for styling nodes. Nodes are often used to show labels, support values, or trait data. They can convey information through variation in their marker shapes (e.g., circles, rectangles, pie-charts), colors, and size. Node markers in `toytree` are represented by SVG shape objects for which a fill (color), fill-opacity, stroke (outline color), stroke-opacity, and stroke-width can be set. \n",
+    "Plotting node values on a tree is a useful way of representing additional information about trees. See the [Data/Features](/toytree/data) section for details on extracting data from tree objects to plot on nodes. Here we will focus on options available for styling nodes. Nodes are often used to show labels, support values, or trait data. They can convey information through variation in their marker shapes (e.g., circles, rectangles, pie-charts), colors, and size. Node markers in `toytree` are represented by SVG shape objects for which a fill (color), fill-opacity, stroke (outline color), stroke-opacity, and stroke-width can be set. \n",
     "\n",
     "Below is a complex example showing how "
    ]
@@ -789,7 +789,7 @@
    "metadata": {},
    "source": [
     "### node_sizes\n",
-    "In the default tree style node sizes are set to zero, meaning that they will not be shown. Node sizes are described in pixel units as floats or ints, which scale node marker sizes. A single value can be entered to apply to all nodes, or a sequence of values of length nnodes can be entered to scale nodes to different sizes. In this case, the values should be enetered in node idxorder, which is best done by extracting data from the tree object itself, as described in [Data/Features](/data). See also [Range-Mapping](/range-mapping) for examples of scaling node sizes to data features. "
+    "In the default tree style node sizes are set to zero, meaning that they will not be shown. Node sizes are described in pixel units as floats or ints, which scale node marker sizes. A single value can be entered to apply to all nodes, or a sequence of values of length nnodes can be entered to scale nodes to different sizes. In this case, the values should be enetered in node idxorder, which is best done by extracting data from the tree object itself, as described in [Data/Features](/toytree/data). See also [Range-Mapping](/toytree/range-mapping) for examples of scaling node sizes to data features. "
    ]
   },
   {
@@ -1211,7 +1211,7 @@
    "id": "5fbca296-cf45-40db-b982-ce79f3f6f02e",
    "metadata": {},
    "source": [
-    "Automatically color nodes by projecting a data feature that is saved to tree object, such as the node heights, using [color-mapping](color-mapping)."
+    "Automatically color nodes by projecting a data feature that is saved to tree object, such as the node heights, using [color-mapping](/toytree/color-mapping)."
    ]
   },
   {

docs/multitree.ipynb

@@ -366,7 +366,7 @@
    "metadata": {},
    "source": [
     "## Consensus trees\n",
-    "A majority-rule consensus tree is a tree that represents the most common non-conflicting splits among a set of input trees. In `toytree` this can be inferred from a `MultiTree` object using the `.get_consensus_tree`, which returns a `ToyTree` with the consensus topology on which several types of statistics have been stored to nodes. This can be useful in several contexts, but one of the simplest is to find the most common order of tip names among a set of trees, so that when you make a `MultiTree` plot you can order tips in the same way to more easily visualize variation among trees. There are many options and uses for consensus trees, check out the [Consensus Trees](/consensus-trees) documentation section for more details.\n",
+    "A majority-rule consensus tree is a tree that represents the most common non-conflicting splits among a set of input trees. In `toytree` this can be inferred from a `MultiTree` object using the `.get_consensus_tree`, which returns a `ToyTree` with the consensus topology on which several types of statistics have been stored to nodes. This can be useful in several contexts, but one of the simplest is to find the most common order of tip names among a set of trees, so that when you make a `MultiTree` plot you can order tips in the same way to more easily visualize variation among trees. There are many options and uses for consensus trees, check out the [Consensus Trees](/toytree/consensus-trees) documentation section for more details.\n",
     "\n",
     "In the example below we get a consensus tree from the `mtree1` multitree object which contains 8 trees. The support values on this returned tree represent the proportion of trees in the input set that contain each clade in the consensus tree. By default, the returned tree is unrooted, since the input trees may vary in their rooting. Here the trees exhibit variation in the relationships among `(a,b,d,e)` with `(a,b)` and `(d,e)` each occurring in 75% of trees."
    ]
@@ -448,7 +448,7 @@
    "metadata": {},
    "source": [
     "### Grid tree drawings\n",
-    "The `.draw()` function of a `MultiTree` returns multiple tree drawings layed out on a grid. The shape of the grid, and which trees from the tree set are drawn, can be set with the `shape` and `idxs` arguments. This also accepts all of the standard drawing arguments that can be used when drawing individual trees. See [Drawing Tree Grids](/drawing-tree-grids)."
+    "The `.draw()` function of a `MultiTree` returns multiple tree drawings layed out on a grid. The shape of the grid, and which trees from the tree set are drawn, can be set with the `shape` and `idxs` arguments. This also accepts all of the standard drawing arguments that can be used when drawing individual trees. See [Drawing Tree Grids](/toytree/drawing-tree-grids)."
    ]
   },
   {
@@ -481,7 +481,7 @@
    "metadata": {},
    "source": [
     "### Cloud tree drawings\n",
-    "It is sometimes even more informative to plot a number of trees on top of each other to visualize their discordance. These are sometimes called “densitree” plots, or here, “cloud tree plots”. See the documentation section on [Drawing Cloud Trees](./drawing-cloud-trees) for more details and examples."
+    "It is sometimes even more informative to plot a number of trees on top of each other to visualize their discordance. These are sometimes called “densitree” plots, or here, “cloud tree plots”. See the documentation section on [Drawing Cloud Trees](#drawing-cloud-trees) for more details and examples."
    ]
   },
   {

docs/node.ipynb

@@ -317,7 +317,7 @@
    "metadata": {},
    "source": [
     "### idx: <span style=\"color:gray\">int</span>\n",
-    "The default `idx` attribute is an int value of -1, which means that the node is not part of a `ToyTree`. If a node is in a `ToyTree` then it will be assigned a unique idx integer between 0 and nnodes-1. The leaf nodes in a tree have idx values between 0 and ntips - 1, and all internal nodes are labeled by increasing numbers in a post-order left-then-right traversal. This is termed an idxorder traversal. When a tree structure changes (e.g. during re-rooting) the idx values of nodes are updated and can change (see [Traversal](/traversal/)). A node's idx value can be checked from its `.idx` attribute, or if it is in a `ToyTree` then by calling `.get_node_data()` or plotting the tree to visualize idx values.  "
+    "The default `idx` attribute is an int value of -1, which means that the node is not part of a `ToyTree`. If a node is in a `ToyTree` then it will be assigned a unique idx integer between 0 and nnodes-1. The leaf nodes in a tree have idx values between 0 and ntips - 1, and all internal nodes are labeled by increasing numbers in a post-order left-then-right traversal. This is termed an idxorder traversal. When a tree structure changes (e.g. during re-rooting) the idx values of nodes are updated and can change (see [Traversal](/toytree/traversal/)). A node's idx value can be checked from its `.idx` attribute, or if it is in a `ToyTree` then by calling `.get_node_data()` or plotting the tree to visualize idx values.  "
    ]
   },
   {
@@ -852,7 +852,7 @@
    "metadata": {},
    "source": [
     "## Nodes vs 'Edges'\n",
-    "Notably, `toytree` does not implement a separate \"Edge\" class to represent edges in a tree. Instead, edges are simply represented by the connections between `Node` objects -- by their `.up` and `.children` attributes. (This can be important when storing new data types to a tree; see [Edge features](/data/#node-vs-edge-features)). Thus you can think of edges as pairs of nodes. You can fetch the edge information from a `ToyTree` in a variety of ways. Below we use the function `get_edges` which has options for returning this information in a number of tabular formats."
+    "Notably, `toytree` does not implement a separate \"Edge\" class to represent edges in a tree. Instead, edges are simply represented by the connections between `Node` objects -- by their `.up` and `.children` attributes. (This can be important when storing new data types to a tree; see [Edge features](/toytree/data/#node-vs-edge-features)). Thus you can think of edges as pairs of nodes. You can fetch the edge information from a `ToyTree` in a variety of ways. Below we use the function `get_edges` which has options for returning this information in a number of tabular formats."
    ]
   },
   {

docs/rooting.ipynb

@@ -1287,7 +1287,7 @@
     "\n",
     "The processes of rooting, unrooting, or re-rooting trees should be reversible, meaning that the operations can be performed in any order without the loss of information about the topology, branch lengths, or any associated meta-data/features. This is the goal in `toytree` and it is always achieved for the case of the topology and branch lengths, but requires some user knowledge when dealing with arbitrary additional data features assigned to the tree. \n",
     "\n",
-    "This is because data can be stored to a tree as either a feature of nodes, or of edges (see [Node-vs-edge-features](data/#node-vs-edge-features)).\n",
+    "This is because data can be stored to a tree as either a feature of nodes, or of edges (see [Node-vs-edge-features](/toytree/data/#node-vs-edge-features)).\n",
     "\n",
     "Some data stored to a tree are intended to represent information about the edges (splits) in a tree, rather than information about the nodes. This is important as these types of data must be treated differently when doing things like re-rooting a tree, and in some cases, for visualization.\n",
     "\n",