Docs: fix linting issues

Author: snejus

docs/_templates/autosummary/base.rst

@@ -1,3 +1,3 @@
 {{ fullname | escape | underline}}
 .. currentmodule:: {{ module }}
-.. auto{{ objtype }}:: {{ objname }}
+.. auto{{ objtype }}:: {{ objname }}

docs/_templates/autosummary/class.rst

@@ -3,10 +3,10 @@
 .. currentmodule:: {{ module }}
 
 .. autoclass:: {{ objname }}
-   :members:                                    <-- add at least this line
+   :members:             <-- add at least this line
    :private-members:
-   :show-inheritance:                           <-- plus I want to show inheritance...
-   :inherited-members:                          <-- ...and inherited members too
+   :show-inheritance:    <-- plus I want to show inheritance...
+   :inherited-members:   <-- ...and inherited members too
 
    {% block methods %}
    .. automethod:: __init__
@@ -25,4 +25,3 @@
    {% endblock %}
 
    .. rubric:: {{ _('Methods definition') }}
-

docs/_templates/autosummary/module.rst

@@ -8,4 +8,4 @@
 
 {%- endfor %}
 {% endif %}
-{% endblock %}
+{% endblock %}

docs/api/database.rst

@@ -44,4 +44,4 @@ Queries
 
     Query
     FieldQuery
-    AndQuery
+    AndQuery

docs/changelog.rst

@@ -20,14 +20,15 @@ invocation of beets usually has only one :class:`Library`. It's powered by
 abstraction, something like a very minimal `ORM`_. The library is also
 responsible for handling queries to retrieve stored objects.
 
-Overview 
+Overview
 ''''''''
 
 You can add new items or albums to the library via the
 :py:meth:`Library.add` and :py:meth:`Library.add_album` methods.
 
 You may also query the library for items and albums using the
-:py:meth:`Library.items`, :py:meth:`Library.albums`, :py:meth:`Library.get_item` and :py:meth:`Library.get_album` methods.
+:py:meth:`Library.items`, :py:meth:`Library.albums`, :py:meth:`Library.get_item`
+and :py:meth:`Library.get_album` methods.
 
 Any modifications to the library must go through a
 :class:`Transaction` object, which you can get using the
@@ -64,7 +65,7 @@ We provide CRUD-like methods for interacting with the database:
 
 * :py:meth:`LibModel.store`
 * :py:meth:`LibModel.load`
-* :py:meth:`LibModel.remove` 
+* :py:meth:`LibModel.remove`
 * :py:meth:`LibModel.add`
 
 The base class :class:`beets.dbcore.Model` has a ``dict``-like interface, so

docs/dev/library.rst

@@ -151,50 +151,50 @@ registration process in this case::
 
 The events currently available are:
 
-* `pluginload`: called after all the plugins have been loaded after the ``beet``
-  command starts
+* ``pluginload``: called after all the plugins have been loaded after the
+  ``beet`` command starts
 
-* `import`: called after a ``beet import`` command finishes (the ``lib`` keyword
-  argument is a Library object; ``paths`` is a list of paths (strings) that were
-  imported)
+* ``import``: called after a ``beet import`` command finishes (the ``lib``
+  keyword argument is a Library object; ``paths`` is a list of paths (strings)
+  that were imported)
 
-* `album_imported`: called with an ``Album`` object every time the ``import``
+* ``album_imported``: called with an ``Album`` object every time the ``import``
   command finishes adding an album to the library. Parameters: ``lib``,
   ``album``
 
-* `album_removed`: called with an ``Album`` object every time an album is
+* ``album_removed``: called with an ``Album`` object every time an album is
   removed from the library (even when its file is not deleted from disk).
 
-* `item_copied`: called with an ``Item`` object whenever its file is copied.
+* ``item_copied``: called with an ``Item`` object whenever its file is copied.
   Parameters: ``item``, ``source`` path, ``destination`` path
 
-* `item_imported`: called with an ``Item`` object every time the importer adds a
-  singleton to the library (not called for full-album imports). Parameters:
-  ``lib``, ``item``
+* ``item_imported``: called with an ``Item`` object every time the importer
+  adds a singleton to the library (not called for full-album imports).
+  Parameters: ``lib``, ``item``
 
-* `before_item_moved`: called with an ``Item`` object immediately before its
+* ``before_item_moved``: called with an ``Item`` object immediately before its
   file is moved. Parameters: ``item``, ``source`` path, ``destination`` path
 
-* `item_moved`: called with an ``Item`` object whenever its file is moved.
+* ``item_moved``: called with an ``Item`` object whenever its file is moved.
   Parameters: ``item``, ``source`` path, ``destination`` path
 
-* `item_linked`: called with an ``Item`` object whenever a symlink is created
+* ``item_linked``: called with an ``Item`` object whenever a symlink is created
   for a file.
   Parameters: ``item``, ``source`` path, ``destination`` path
 
-* `item_hardlinked`: called with an ``Item`` object whenever a hardlink is
+* ``item_hardlinked``: called with an ``Item`` object whenever a hardlink is
   created for a file.
   Parameters: ``item``, ``source`` path, ``destination`` path
 
-* `item_reflinked`: called with an ``Item`` object whenever a reflink is
+* ``item_reflinked``: called with an ``Item`` object whenever a reflink is
   created for a file.
   Parameters: ``item``, ``source`` path, ``destination`` path
 
-* `item_removed`: called with an ``Item`` object every time an item (singleton
+* ``item_removed``: called with an ``Item`` object every time an item (singleton
   or album's part) is removed from the library (even when its file is not
   deleted from disk).
 
-* `write`: called with an ``Item`` object, a ``path``, and a ``tags``
+* ``write``: called with an ``Item`` object, a ``path``, and a ``tags``
   dictionary just before a file's metadata is written to disk (i.e.,
   just before the file on disk is opened). Event handlers may change
   the ``tags`` dictionary to customize the tags that are written to the
@@ -203,84 +203,83 @@ The events currently available are:
   operation. Beets will catch that exception, print an error message
   and continue.
 
-* `after_write`: called with an ``Item`` object after a file's metadata is
+* ``after_write``: called with an ``Item`` object after a file's metadata is
   written to disk (i.e., just after the file on disk is closed).
 
-* `import_task_created`: called immediately after an import task is
-  initialized. Plugins can use this to, for example, change imported files of a
-  task before anything else happens. It's also possible to replace the task
-  with another task by returning a list of tasks. This list can contain zero
-  or more `ImportTask`s. Returning an empty list will stop the task.
-  Parameters: ``task`` (an `ImportTask`) and ``session`` (an `ImportSession`).
+* ``import_task_created``: called immediately after an import task is
+  initialized. Plugins can use this to, for example, change imported files of
+  a task before anything else happens. It's also possible to replace the task
+  with another task by returning a list of tasks. This list can contain zero or
+  more ``ImportTask``. Returning an empty list will stop the task.
+  Parameters: ``task`` (an ``ImportTask``) and ``session`` (an
+  ``ImportSession``).
 
-* `import_task_start`: called when before an import task begins processing.
+* ``import_task_start``: called when before an import task begins processing.
   Parameters: ``task`` and ``session``.
 
-* `import_task_apply`: called after metadata changes have been applied in an
+* ``import_task_apply``: called after metadata changes have been applied in an
   import task. This is called on the same thread as the UI, so use this
   sparingly and only for tasks that can be done quickly. For most plugins, an
   import pipeline stage is a better choice (see :ref:`plugin-stage`).
   Parameters: ``task`` and ``session``.
 
-* `import_task_before_choice`: called after candidate search for an import task
-  before any decision is made about how/if to import or tag. Can be used to
-  present information about the task or initiate interaction with the user
+* ``import_task_before_choice``: called after candidate search for an import
+  task before any decision is made about how/if to import or tag. Can be used
+  to present information about the task or initiate interaction with the user
   before importing occurs. Return an importer action to take a specific action.
   Only one handler may return a non-None result.
   Parameters: ``task`` and ``session``
 
-* `import_task_choice`: called after a decision has been made about an import
+* ``import_task_choice``: called after a decision has been made about an import
   task. This event can be used to initiate further interaction with the user.
   Use ``task.choice_flag`` to determine or change the action to be
   taken. Parameters: ``task`` and ``session``.
 
-* `import_task_files`: called after an import task finishes manipulating the
+* ``import_task_files``: called after an import task finishes manipulating the
   filesystem (copying and moving files, writing metadata tags). Parameters:
   ``task`` and ``session``.
 
-* `library_opened`: called after beets starts up and initializes the main
+* ``library_opened``: called after beets starts up and initializes the main
   Library object. Parameter: ``lib``.
 
-* `database_change`: a modification has been made to the library database. The
+* ``database_change``: a modification has been made to the library database. The
   change might not be committed yet. Parameters: ``lib`` and ``model``.
 
-* `cli_exit`: called just before the ``beet`` command-line program exits.
+* ``cli_exit``: called just before the ``beet`` command-line program exits.
   Parameter: ``lib``.
 
-* `import_begin`: called just before a ``beet import`` session starts up.
+* ``import_begin``: called just before a ``beet import`` session starts up.
   Parameter: ``session``.
 
-* `trackinfo_received`: called after metadata for a track item has been
+* ``trackinfo_received``: called after metadata for a track item has been
   fetched from a data source, such as MusicBrainz. You can modify the tags
   that the rest of the pipeline sees on a ``beet import`` operation or during
   later adjustments, such as ``mbsync``. Slow handlers of the event can impact
   the operation, since the event is fired for any fetched possible match
-  `before` the user (or the autotagger machinery) gets to see the match.
+  ``before`` the user (or the autotagger machinery) gets to see the match.
   Parameter: ``info``.
 
-* `albuminfo_received`: like `trackinfo_received`, the event indicates new
+* ``albuminfo_received``: like ``trackinfo_received``, the event indicates new
   metadata for album items. The parameter is an ``AlbumInfo`` object instead
   of a ``TrackInfo``.
   Parameter: ``info``.
 
-* `before_choose_candidate`: called before the user is prompted for a decision
+* ``before_choose_candidate``: called before the user is prompted for a decision
   during a ``beet import`` interactive session. Plugins can use this event for
   :ref:`appending choices to the prompt <append_prompt_choices>` by returning a
   list of ``PromptChoices``. Parameters: ``task`` and ``session``.
-
-* `mb_track_extract`: called after the metadata is obtained from
-  MusicBrainz. The parameter is a ``dict`` containing the tags retrieved from
-  MusicBrainz for a track. Plugins must return a new (potentially empty)
-  ``dict`` with additional ``field: value`` pairs, which the autotagger will
-  apply to the item, as flexible attributes if ``field`` is not a hardcoded
-  field. Fields already present on the track are overwritten.
-  Parameter: ``data``
-
-* `mb_album_extract`: Like `mb_track_extract`, but for album tags. Overwrites
-  tags set at the track level, if they have the same ``field``.
+* ``mb_track_extract``: called after the metadata is obtained from MusicBrainz.
+  The parameter is a ``dict`` containing the tags retrieved from MusicBrainz for
+  a track. Plugins must return a new (potentially empty) ``dict`` with
+  additional ``field: value`` pairs, which the autotagger will apply to the
+  item, as flexible attributes if ``field`` is not a hardcoded field. Fields
+  already present on the track are overwritten. Parameter: ``data``
+* ``mb_album_extract``: Like ``mb_track_extract``, but for album tags.
+  Overwrites tags set at the track level, if they have the same ``field``.
   Parameter: ``data``
 
-The included ``mpdupdate`` plugin provides an example use case for event listeners.
+The included ``mpdupdate`` plugin provides an example use case for event
+listeners.
 
 Extend the Autotagger
 ^^^^^^^^^^^^^^^^^^^^^
@@ -330,10 +329,10 @@ Read Configuration Options
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Plugins can configure themselves using the ``config.yaml`` file. You can read
-configuration values in two ways. The first is to use `self.config` within
+configuration values in two ways. The first is to use ``self.config`` within
 your plugin class. This gives you a view onto the configuration values in a
 section with the same name as your plugin's module. For example, if your plugin
-is in ``greatplugin.py``, then `self.config` will refer to options under the
+is in ``greatplugin.py``, then ``self.config`` will refer to options under the
 ``greatplugin:`` section of the config file.
 
 For example, if you have a configuration value called "foo", then users can put
@@ -343,19 +342,19 @@ this in their ``config.yaml``::
         foo: bar
 
 To access this value, say ``self.config['foo'].get()`` at any point in your
-plugin's code. The `self.config` object is a *view* as defined by the `Confuse`_
-library.
+plugin's code. The ``self.config`` object is a *view* as defined by the
+`Confuse`_ library.
 
 .. _Confuse: https://confuse.readthedocs.io/en/latest/
 
 If you want to access configuration values *outside* of your plugin's section,
-import the `config` object from the `beets` module. That is, just put ``from
+import the ``config`` object from the ``beets`` module. That is, just put ``from
 beets import config`` at the top of your plugin and access values from there.
 
 If your plugin provides configuration values for sensitive data (e.g.,
 passwords, API keys, ...), you should add these to the config so they can be
 redacted automatically when users dump their config. This can be done by
-setting each value's `redact` flag, like so::
+setting each value's ``redact`` flag, like so::
 
     self.config['password'].redact = True
 
@@ -421,7 +420,7 @@ to extend the kinds of metadata that they can easily manage.
 
 The ``MediaFile`` class uses ``MediaField`` descriptors to provide
 access to file tags. If you have created a descriptor you can add it through
-your plugins :py:meth:`beets.plugins.BeetsPlugin.add_media_field()`` method.
+your plugins :py:meth:`beets.plugins.BeetsPlugin.add_media_field()` method.
 
 .. _MediaFile: https://mediafile.readthedocs.io/en/latest/
 
@@ -462,9 +461,9 @@ Multiple stages run in parallel but each stage processes only one task at a time
 and each task is processed by only one stage at a time.
 
 Plugins provide stages as functions that take two arguments: ``config`` and
-``task``, which are ``ImportSession`` and ``ImportTask`` objects (both defined in
-``beets.importer``). Add such a function to the plugin's ``import_stages`` field
-to register it::
+``task``, which are ``ImportSession`` and ``ImportTask`` objects (both defined
+in ``beets.importer``). Add such a function to the plugin's ``import_stages``
+field to register it::
 
     from beets.plugins import BeetsPlugin
     class ExamplePlugin(BeetsPlugin):
@@ -543,11 +542,11 @@ should have an integer type::
         def album_types(self):
             return {'rating': types.INTEGER}
 
-A plugin may define two attributes: `item_types` and `album_types`.
+A plugin may define two attributes: ``item_types`` and ``album_types``.
 Each of those attributes is a dictionary mapping a flexible field name
 to a type instance. You can find the built-in types in the
-`beets.dbcore.types` and `beets.library` modules or implement your own
-type by inheriting from the `Type` class.
+``beets.dbcore.types`` and ``beets.library`` modules or implement your own
+type by inheriting from the ``Type`` class.
 
 Specifying types has several advantages:
 

docs/dev/plugins.rst

@@ -161,12 +161,11 @@ it's helpful to run on the "bleeding edge". To run the latest source:
          git clone https://github.com/beetbox/beets.git
          poetry install
 
-      This approach lets you decide where the
-      source is stored, with any changes immediately reflected in your
-      environment.
+      This approach lets you decide where the source is stored, with any
+      changes immediately reflected in your environment.
 
-More details about the beets source are available on the :doc:`developer documentation </dev/index>`
-pages.
+More details about the beets source are available on the :doc:`developer
+documentation </dev/index>` pages.
 
 
 .. _bugs:
@@ -240,7 +239,8 @@ move all your files.
 If you've already moved your music *outside* of beets, you have a few options:
 
 - Move the music back (with an ordinary ``mv``) and then use the above steps.
-- Delete your database and re-create it from the new paths using ``beet import -AWC``.
+- Delete your database and re-create it from the new paths using ``beet import
+  -AWC``.
 - Resort to manually modifying the SQLite database (not recommended).
 
 

docs/faq.rst

@@ -109,8 +109,8 @@ using the :ref:`modify-cmd` command::
 
 By default, beets will show you the changes that are about to be applied and ask
 if you really want to apply them to all, some or none of the items or albums.
-You can type y for "yes", n for "no", or s for "select". If you choose the latter,
-the command will prompt you for each individual matching item or album.
+You can type y for "yes", n for "no", or s for "select". If you choose the
+latter, the command will prompt you for each individual matching item or album.
 
 Then :doc:`query </reference/query>` your music just as you would with any
 other field::