Refs #36485 -- Rewrapped docs to 79 columns line length.

Lines in the docs files were manually adjusted to conform to the
79 columns limit per line (plus newline), improving readability and
consistency across the content.

docs/topics/db/queries.txt

@@ -518,8 +518,8 @@ probably use:
     case-insensitive versions called :lookup:`istartswith` and
     :lookup:`iendswith`.
 
-Again, this only scratches the surface. A complete reference can be found in the
-:ref:`field lookup reference <field-lookups>`.
+Again, this only scratches the surface. A complete reference can be found in
+the :ref:`field lookup reference <field-lookups>`.
 
 .. _lookups-that-span-relationships:
 
@@ -706,10 +706,10 @@ and use that ``F()`` object in the query:
     >>> from django.db.models import F
     >>> Entry.objects.filter(number_of_comments__gt=F("number_of_pingbacks"))
 
-Django supports the use of addition, subtraction, multiplication,
-division, modulo, and power arithmetic with ``F()`` objects, both with constants
-and with other ``F()`` objects. To find all the blog entries with more than
-*twice* as many comments as pingbacks, we modify the query:
+Django supports the use of addition, subtraction, multiplication, division,
+modulo, and power arithmetic with ``F()`` objects, both with constants and with
+other ``F()`` objects. To find all the blog entries with more than *twice* as
+many comments as pingbacks, we modify the query:
 
 .. code-block:: pycon
 
@@ -1370,7 +1370,8 @@ Complex lookups with ``Q`` objects
 
 Keyword argument queries -- in :meth:`~django.db.models.query.QuerySet.filter`,
 etc. -- are "AND"ed together. If you need to execute more complex queries (for
-example, queries with ``OR`` statements), you can use :class:`Q objects <django.db.models.Q>`.
+example, queries with ``OR`` statements), you can use
+:class:`Q objects <django.db.models.Q>`.
 
 A :class:`Q object <django.db.models.Q>` (``django.db.models.Q``) is an object
 used to encapsulate a collection of keyword arguments. These keyword arguments
@@ -1688,9 +1689,9 @@ When you define a relationship in a model (i.e., a
 :class:`~django.db.models.ManyToManyField`), instances of that model will have
 a convenient API to access the related object(s).
 
-Using the models at the top of this page, for example, an ``Entry`` object ``e``
-can get its associated ``Blog`` object by accessing the ``blog`` attribute:
-``e.blog``.
+Using the models at the top of this page, for example, an ``Entry`` object
+``e`` can get its associated ``Blog`` object by accessing the ``blog``
+attribute: ``e.blog``.
 
 (Behind the scenes, this functionality is implemented by Python
 :doc:`descriptors <python:howto/descriptor>`. This shouldn't really matter to
@@ -1805,9 +1806,9 @@ Using a custom reverse manager
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 By default the :class:`~django.db.models.fields.related.RelatedManager` used
-for reverse relations is a subclass of the :ref:`default manager <manager-names>`
-for that model. If you would like to specify a different manager for a given
-query you can use the following syntax::
+for reverse relations is a subclass of the :ref:`default manager
+<manager-names>` for that model. If you would like to specify a different
+manager for a given query you can use the following syntax::
 
     from django.db import models
 
@@ -1941,9 +1942,9 @@ For example::
     ed.entry  # Returns the related Entry object.
 
 The difference comes in "reverse" queries. The related model in a one-to-one
-relationship also has access to a :class:`~django.db.models.Manager` object, but
-that :class:`~django.db.models.Manager` represents a single object, rather than
-a collection of objects::
+relationship also has access to a :class:`~django.db.models.Manager` object,
+but that :class:`~django.db.models.Manager` represents a single object, rather
+than a collection of objects::
 
     e = Entry.objects.get(id=2)
     e.entrydetail  # returns the related EntryDetail object