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/auth/customizing.txt

@@ -81,8 +81,8 @@ backends that follow.
     for the duration of that session whenever access to the currently
     authenticated user is needed. This effectively means that authentication
     sources are cached on a per-session basis, so if you change
-    :setting:`AUTHENTICATION_BACKENDS`, you'll need to clear out session data if
-    you need to force users to re-authenticate using different methods. A
+    :setting:`AUTHENTICATION_BACKENDS`, you'll need to clear out session data
+    if you need to force users to re-authenticate using different methods. A
     simple way to do that is to execute ``Session.objects.all().delete()``.
 
 Writing an authentication backend
@@ -474,8 +474,8 @@ different user model.
     Instead of referring to :class:`~django.contrib.auth.models.User` directly,
     you should reference the user model using
     ``django.contrib.auth.get_user_model()``. This method will return the
-    currently active user model -- the custom user model if one is specified, or
-    :class:`~django.contrib.auth.models.User` otherwise.
+    currently active user model -- the custom user model if one is specified,
+    or :class:`~django.contrib.auth.models.User` otherwise.
 
     When you define a foreign key or many-to-many relations to the user model,
     you should specify the custom model using the :setting:`AUTH_USER_MODEL`
@@ -491,8 +491,8 @@ different user model.
                 on_delete=models.CASCADE,
             )
 
-    When connecting to signals sent by the user model, you should specify
-    the custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
+    When connecting to signals sent by the user model, you should specify the
+    custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
 
         from django.conf import settings
         from django.db.models.signals import post_save
@@ -682,9 +682,9 @@ The following attributes and methods are available on any subclass of
     .. attribute:: models.AbstractBaseUser.is_anonymous
 
         Read-only attribute which is always ``False``. This is a way of
-        differentiating :class:`~models.User` and :class:`~models.AnonymousUser`
-        objects. Generally, you should prefer using
-        :attr:`~models.User.is_authenticated` to this attribute.
+        differentiating :class:`~models.User` and
+        :class:`~models.AnonymousUser` objects. Generally, you should prefer
+        using :attr:`~models.User.is_authenticated` to this attribute.
 
     .. method:: models.AbstractBaseUser.set_password(raw_password)
 
@@ -710,8 +710,8 @@ The following attributes and methods are available on any subclass of
 
         Marks the user as having no password set. This isn't the same as
         having a blank string for a password.
-        :meth:`~django.contrib.auth.models.AbstractBaseUser.check_password` for this user
-        will never return ``True``. Doesn't save the
+        :meth:`~django.contrib.auth.models.AbstractBaseUser.check_password` for
+        this user will never return ``True``. Doesn't save the
         :class:`~django.contrib.auth.models.AbstractBaseUser` object.
 
         You may need this if authentication for your application takes place
@@ -720,8 +720,8 @@ The following attributes and methods are available on any subclass of
     .. method:: models.AbstractBaseUser.has_usable_password()
 
         Returns ``False`` if
-        :meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password` has
-        been called for this user.
+        :meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password`
+        has been called for this user.
 
     .. method:: models.AbstractBaseUser.get_session_auth_hash()
 
@@ -751,8 +751,9 @@ defines ``username``, ``email``, ``is_staff``, ``is_active``, ``is_superuser``,
 ``last_login``, and ``date_joined`` fields the same as Django's default user,
 you can install Django's :class:`~django.contrib.auth.models.UserManager`;
 however, if your user model defines different fields, you'll need to define a
-custom manager that extends :class:`~django.contrib.auth.models.BaseUserManager`
-providing two additional methods:
+custom manager that extends
+:class:`~django.contrib.auth.models.BaseUserManager` providing two additional
+methods:
 
 .. class:: models.CustomUserManager
 
@@ -808,10 +809,11 @@ utility methods:
 Extending Django's default ``User``
 -----------------------------------
 
-If you're entirely happy with Django's :class:`~django.contrib.auth.models.User`
-model, but you want to add some additional profile information, you could
-subclass :class:`django.contrib.auth.models.AbstractUser` and add your custom
-profile fields, although we'd recommend a separate model as described in
+If you're entirely happy with Django's
+:class:`~django.contrib.auth.models.User` model, but you want to add some
+additional profile information, you could subclass
+:class:`django.contrib.auth.models.AbstractUser` and add your custom profile
+fields, although we'd recommend a separate model as described in
 :ref:`specifying-custom-user-model`. ``AbstractUser`` provides the full
 implementation of the default :class:`~django.contrib.auth.models.User` as an
 :ref:`abstract model <abstract-base-classes>`.

docs/topics/auth/default.txt

@@ -1042,8 +1042,8 @@ arguments in the URLconf, these will be passed on to the view. For example::
         ),
     ]
 
-All views are :doc:`class-based </topics/class-based-views/index>`, which allows
-you to easily customize them by subclassing.
+All views are :doc:`class-based </topics/class-based-views/index>`, which
+allows you to easily customize them by subclassing.
 
 .. _all-authentication-views:
 
@@ -1155,8 +1155,8 @@ implementation details see :ref:`using-the-views`.
       For more on sites, see :doc:`/ref/contrib/sites`.
 
     If you'd prefer not to call the template :file:`registration/login.html`,
-    you can pass the ``template_name`` parameter via the extra arguments to
-    the ``as_view`` method in your URLconf. For example, this URLconf line would
+    you can pass the ``template_name`` parameter via the extra arguments to the
+    ``as_view`` method in your URLconf. For example, this URLconf line would
     use :file:`myapp/login.html` instead::
 
         path("accounts/login/", auth_views.LoginView.as_view(template_name="myapp/login.html")),
@@ -1799,8 +1799,8 @@ the logged-in user has any permissions in the ``foo`` app:
     {% if perms.foo %}
 
 Evaluating a two-level-attribute lookup as a boolean is a proxy to
-:meth:`User.has_perm() <django.contrib.auth.models.User.has_perm>`. For example,
-to check if the logged-in user has the permission ``foo.add_vote``:
+:meth:`User.has_perm() <django.contrib.auth.models.User.has_perm>`. For
+example, to check if the logged-in user has the permission ``foo.add_vote``:
 
 .. code-block:: html+django
 

docs/topics/auth/passwords.txt

@@ -211,8 +211,8 @@ hashing. This deliberately slows down attackers, making attacks against hashed
 passwords harder. However, as computing power increases, the number of
 iterations needs to be increased. We've chosen a reasonable default (and will
 increase it with each release of Django), but you may wish to tune it up or
-down, depending on your security needs and available processing power. To do so,
-you'll subclass the appropriate algorithm and override the ``iterations``
+down, depending on your security needs and available processing power. To do
+so, you'll subclass the appropriate algorithm and override the ``iterations``
 parameter (use the ``rounds`` parameter when subclassing a bcrypt hasher). For
 example, to increase the number of iterations used by the default PBKDF2
 algorithm: