Merge pull request #1049 from datalad-handbook/more-random-stuff

add some words to prevent an awkward line break

docs/basics/101-123-config2.rst

@@ -148,7 +148,7 @@ There is one right in the root of your dataset:
    $ cat .gitmodules
 
 Based on these contents, you might have already guessed what this file
-stores. ``.gitmodules`` is a configuration file that stores the mapping between
+stores. The ``.gitmodules`` file is a configuration file that stores the mapping between
 your own dataset and any subdatasets you have installed in it.
 There will be an entry for each submodule (subdataset) in your dataset.
 The name *submodule* is Git terminology, and describes a Git repository inside of
@@ -257,7 +257,7 @@ Here is the directory structure:
       add (ok: 2)
       save (ok: 1)
 
-Now, we can apply the ``datalad-recursiveinstall`` configuration to skip recursive installations for subds1
+Now, we can apply the ``datalad-recursiveinstall`` configuration to skip recursive installations for ``subds1``
 
 .. code-block:: bash
 
@@ -475,7 +475,7 @@ This has been an intense lecture, you have to admit. One definite
 take-away from it has been that you now know a second reason why the hidden
 ``.git`` and ``.datalad`` directory contents and also the contents of ``.gitmodules`` and
 ``.gitattributes`` should not be carelessly tampered with -- they contain all of
-the repositories configurations.
+the repository's configurations.
 
 But you now also know how to modify these configurations with enough
 care and background knowledge such that nothing should go wrong once you

docs/basics/101-124-procedures.rst

@@ -73,7 +73,7 @@ What makes them a particularly versatile and flexible tool is
 that anyone can write their own procedures.
 If a workflow is a standard in a team and needs to be applied often, turning it into
 a script can save time and effort.
-To learn how to do this, read the :ref:`with a tutorial on writing own procedures <fom-procedures>`.
+To learn how to do this, read the :ref:`tutorial on writing own procedures <fom-procedures>`.
 By pointing DataLad to the location the procedures reside in they can be applied, and by
 including them in a dataset they can even be shared.
 And even if the script is simple, it is very handy to have preconfigured

docs/basics/101-125-summary.rst

@@ -14,7 +14,7 @@ your horizon about configurations of datasets:
   ``.datalad/config`` that apply to a specific dataset, but are committed and
   therefore distributed. More specialized scopes take precedence over more global scopes.
 
-- Almost all configurations can be set with the :gitcmd:`config`.
+- Almost all configurations can be set with the :gitcmd:`config` command.
   Its structure looks like this:
 
   .. code-block:: bash
@@ -32,7 +32,7 @@ your horizon about configurations of datasets:
   in a :gitcmd:`config` command.
 
 - The ``.gitattributes`` file is the only configuration file the :gitcmd:`config`
-  can not write to, because it has a different layout. However, run-procedures or
+  command can not write to, because it has a different layout. However, run-procedures or
   the user can write simple rules into it that determine which files are annexed
   and which are stored in Git.
 

docs/basics/101-130-yodaproject.rst

@@ -341,7 +341,7 @@ To compute the analysis you create the following Python script inside of ``code/
 .. runrecord:: _examples/DL-101-130-107
    :language: console
    :workdir: dl-101/DataLad-101/midterm_project
-   :emphasize-lines: 11-13, 23, 42
+   :emphasize-lines: 11-13, 23, 43
    :cast: 10_yoda
    :notes: Let's create code for an analysis
 
@@ -485,7 +485,7 @@ re-execution with :dlcmd:`rerun` easy.
    - `seaborn <https://seaborn.pydata.org>`_
    - `sklearn <https://scikit-learn.org>`_
 
-   The packages can be installed via ``pip`` [#f3]_.
+   The packages can be installed via :term:`pip`.
    However, if you do not want to install any
    Python packages, do not execute the remaining code examples in this section
    -- an upcoming section on ``datalad containers-run`` will allow you to
@@ -674,8 +674,7 @@ configuration, or interactively).
 
 .. importantnote:: Generate a GitHub token
 
-   GitHub `deprecated user-password authentication <https://developer.github.com/changes/2020-02-14-deprecating-password-auth>`_ supports authentication via personal access token only.
-
+   GitHub `deprecated user-password authentication <https://developer.github.com/changes/2020-02-14-deprecating-password-auth>`_ and instead supports authentication via personal access token.
    To ensure successful authentication, don't supply your password, but create a personal access token at `github.com/settings/tokens <https://github.com/settings/tokens>`_ [#f6]_ instead, and either
 
    * supply the token with the argument ``--github-login <TOKEN>`` from the command line,
@@ -944,8 +943,4 @@ reproduce your data science project easily from scratch (take a look into the :r
 .. [#f5]  Alternatively, if you were to use DataLad's Python API, you could import and expose it as ``dl.<COMMAND>`` and ``dl.get()`` the relevant files. This however, would not record them as provenance in the dataset's history.
 
 .. [#f6] Instead of using GitHub's WebUI you could also obtain a token using the command line GitHub interface (https://github.com/sociomantic-tsunami/git-hub) by running ``git hub setup`` (if no 2FA is used).
-         If you decide to use the command line interface, here is help on how to use it:
-         Clone the `GitHub repository <https://github.com/sociomantic-tsunami/git-hub>`_ to your local computer.
-         Decide whether you want to build a Debian package to install, or install the single-file Python script distributed in the repository.
-         Make sure that all `requirements <https://github.com/sociomantic-tsunami/git-hub>`_ for your preferred version are installed , and run either ``make deb`` followed by ``sudo dpkg -i deb/git-hub*all.deb``, or ``make install``.
 

docs/basics/101-139-hostingservices.rst

@@ -357,6 +357,6 @@ Once you have set up your dataset sibling(s), you can push individual datasets w
          is protecting. If the private key does not have a passphrase, simply copying
          this file grants a person access!
 
-.. [#f3]  GitHub `deprecated user-password authentication <https://developer.github.com/changes/2020-02-14-deprecating-password-auth>`_ and only supports authentication via personal access token from November 13th 2020 onwards. Supplying a password instead of a token will fail to authenticate.
+.. [#f3]  GitHub `deprecated user-password authentication <https://developer.github.com/changes/2020-02-14-deprecating-password-auth>`_ in favor of authentication via personal access token. Supplying a password instead of a token will fail to authenticate.
 
 .. [#f4] The default project name ``project`` and path separator ``-`` are configurable using the dataset-level configurations ``datalad.gitlab-default-projectname`` and ``datalad.gitlab-default-pathseparator``