refactor documentation

docs/howto/append.md

@@ -2,7 +2,7 @@
 
 Sometimes it might be useful to be able to append some text to a
 file. Dotdrop is able to do that with the help of
-[actions](../config-details.md#actions-entry) and a temporary file.
+[actions](../config-actions.md) and a temporary file.
 
 Below is a config example to append to a file:
 ```yaml

docs/howto/create-special-files.md

@@ -1,7 +1,7 @@
 # Create files on install
 
 One way to create symlinks (or any other special file) is to use a combination of
-[actions](../config-details.md#actions-entry) and a *fake* dotfile.
+[actions](../config-actions.md) and a *fake* dotfile.
 
 Let's say, for example, you have a list of directories you want to link
 from under `~/.original` to `~/symlinks`.

docs/howto/merge-files-when-installing.md

@@ -1,6 +1,6 @@
 # Merge files on install
 
-Dotdrop allows you to merge multiple files into one using Jinja2's `include` directive.
+Dotdrop allows to merge multiple files into one using Jinja2's `include` directive.
 
 For example, let's assume you want to keep your `.vimrc` split into multiple parts in dotdrop:
 * `<dotpath>/vimrc.d/top`: top part of the file
@@ -48,12 +48,12 @@ Dotdrop will then automagically include the files into your vimrc when handling
 ## Merge all files in a directory
 
 To include all files in a directory, a combination of
-[dynvariables](../config-details.md#dynvariables-entry)
+[dynvariables](../config-dynvars.md)
 and [Jinja2 directives](https://jinja.palletsprojects.com/en/2.11.x/) have to be used.
 
 Let's say all files in `<dotpath>/toinclude` need to be included into a dotfile.
 
-First define a [dynvariables](../config-details.md#dynvariables-entry)
+First define a [dynvariables](../config-dynvars.md)
 in the config file which will look for files to include in the above directory:
 ```yaml
 dynvariables:

docs/howto/prompt-user-for-variables.md

@@ -1,12 +1,12 @@
 # Prompt user for variables
 
-With the use of [uservariables](../config-details.md#uservariables-entry),
+With the use of [uservariables](../config-uservars.md),
 one can define specific variables that need to be initially filled in manually
 by the user on first run.
 
 The provided values are then automatically saved by dotdrop to `uservariables.yaml`,
 which can be included in the main config as a file from which variables are imported
-using [import_variables](../config-details.md#import_variables-entry).
+using [import_variables](../config-config.md).
 
 Let's say, for example, that you want to manually provide the email value
 on new hosts you deploy your dotfiles to.

docs/howto/sensitive-dotfiles.md

@@ -19,7 +19,7 @@ trans_read:
   _gpg: gpg2 -q --for-your-eyes-only --no-tty -d {0} > {1}
 ```
 
-The above config allows you to store the dotfile `~/.secret` encrypted in the *dotpath*
+The above config allows to store the dotfile `~/.secret` encrypted in the *dotpath*
 directory and uses gpg to decrypt it when `install` is run.
 
 Here's how to deploy the above solution:
@@ -47,7 +47,7 @@ $ cp <encrypted-version-of-secret> dotfiles/secret
 
 * Commit and push the changes
 
-See [transformations](../config-details.md#transformations-entry).
+See [transformations](../config-transformations.md).
 
 ## Load passphrase from file
 
@@ -67,4 +67,4 @@ trans_read:
   _gpg: "gpg2 --batch --yes --passphrase-file <(cat {{@@ gpg_password_file @@}}) -q --for-your-eyes-only --no-tty -d {0} > {1}"
 ```
 
-See [transformations](../config-details.md#transformations-entry).
+See [transformations](../config-transformations.md).

docs/howto/sharing-content.md

@@ -66,7 +66,7 @@ export DB_PORT='4521'
 The previous method, albeit flexible, is a bit cumbersome for some use cases.
 For example, when the dotfiles belong to different profiles, the cleanest
 solution consists of using
-[profile variables](../config-details.md#profile-variables-entry). This is achieved by:
+[profile variables](../config-profiles.md#profile-variables-entry). This is achieved by:
 
 1. Creating the merged dotfile with an arbitrary name somewhere in `dotpath`.
 2. Adding some variables in the merged dotfile via templating.

docs/howto/symlink-dotfiles.md

@@ -86,7 +86,7 @@ after  autoload  plugged  plugin  snippets  spell  swap  vimrc
 As a result, all files under `~/.vim` will be managed by
 dotdrop (including unwanted directories like `spell`, `swap`, etc.).
 
-A cleaner solution is to use `link_children` which allows you to only symlink
+A cleaner solution is to use `link_children` which allows to only symlink
 files under the dotfile directory. Let's say only `after`, `plugin`, `snippets`, and `vimrc`
 need to be managed in dotdrop. `~/.vim` is imported in dotdrop and cleaned of all unwanted
 files/directories, and then the `link` entry is set to `link_children` in the config file:
@@ -121,10 +121,10 @@ $ tree -L 1 ~/.vim
 ## Templating symlinked dotfiles
 
 Dotfiles not using any templating directives are directly linked
-to dotdrop's `dotpath` directory (see [Config](../config.md)).
+to dotdrop's `dotpath` directory (see [the config file doc](../config-file.md)).
 
 When using templating directives, however, the dotfiles are first installed into
-`workdir` (defaults to *~/.config/dotdrop*; see [Config format](../config-format.md))
+`workdir` (defaults to *~/.config/dotdrop*; see [the doc](../config-config.md))
 and then symlinked there.
 This applies to both dotfiles with `link: link` and `link: link_children`.
 

docs/howto/system-config-files.md

@@ -1,6 +1,6 @@
 # Manage system dotfiles
 
-Dotdrop doesn't allow you to handle file owernership (at least not directly). Every file operation (create/copy file/directory, create symlinks, etc.) is executed with the rights of the user calling dotdrop.
+Dotdrop doesn't allow to handle file owernership (at least not directly). Every file operation (create/copy file/directory, create symlinks, etc.) is executed with the rights of the user calling dotdrop.
 
 Using dotdrop with `sudo` to manage unprivileged and privileged files in the same *session* is a bad idea as the resulting files will all have messed-up owners.