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/forms/formsets.txt

@@ -274,12 +274,13 @@ provide this management data, the formset will be invalid:
     >>> formset.is_valid()
     False
 
-It is used to keep track of how many form instances are being displayed. If
-you are adding new forms via JavaScript, you should increment the count fields
-in this form as well. On the other hand, if you are using JavaScript to allow
+It is used to keep track of how many form instances are being displayed. If you
+are adding new forms via JavaScript, you should increment the count fields in
+this form as well. On the other hand, if you are using JavaScript to allow
 deletion of existing objects, then you need to ensure the ones being removed
 are properly marked for deletion by including ``form-#-DELETE`` in the ``POST``
-data. It is expected that all forms are present in the ``POST`` data regardless.
+data. It is expected that all forms are present in the ``POST`` data
+regardless.
 
 The management form is available as an attribute of the formset
 itself. When rendering a formset in a template, you can include all

docs/topics/forms/index.txt

@@ -192,9 +192,9 @@ the user's name. You'd need something like this in your template:
         <input type="submit" value="OK">
     </form>
 
-This tells the browser to return the form data to the URL ``/your-name/``, using
-the ``POST`` method. It will display a text field, labeled "Your name:", and a
-button marked "OK". If the template context contains a ``current_name``
+This tells the browser to return the form data to the URL ``/your-name/``,
+using the ``POST`` method. It will display a text field, labeled "Your name:",
+and a button marked "OK". If the template context contains a ``current_name``
 variable, that will be used to pre-fill the ``your_name`` field.
 
 You'll need a view that renders the template containing the HTML form, and
@@ -203,8 +203,9 @@ that can supply the ``current_name`` field as appropriate.
 When the form is submitted, the ``POST`` request which is sent to the server
 will contain the form data.
 
-Now you'll also need a view corresponding to that ``/your-name/`` URL which will
-find the appropriate key/value pairs in the request, and then process them.
+Now you'll also need a view corresponding to that ``/your-name/`` URL which
+will find the appropriate key/value pairs in the request, and then process
+them.
 
 This is a very simple form. In practice, a form might contain dozens or
 hundreds of fields, many of which might need to be prepopulated, and we might
@@ -343,12 +344,12 @@ from that ``{{ form }}`` by Django's template language.
 
 .. admonition:: Forms and Cross Site Request Forgery protection
 
-    Django ships with an easy-to-use :doc:`protection against Cross Site Request
-    Forgeries </ref/csrf>`. When submitting a form via ``POST`` with
-    CSRF protection enabled you must use the :ttag:`csrf_token` template tag
-    as in the preceding example. However, since CSRF protection is not
-    directly tied to forms in templates, this tag is omitted from the
-    following examples in this document.
+    Django ships with an easy-to-use :doc:`protection against Cross Site
+    Request Forgeries </ref/csrf>`. When submitting a form via ``POST`` with
+    CSRF protection enabled you must use the :ttag:`csrf_token` template tag as
+    in the preceding example. However, since CSRF protection is not directly
+    tied to forms in templates, this tag is omitted from the following examples
+    in this document.
 
 .. admonition:: HTML5 input types and browser validation
 
@@ -381,8 +382,8 @@ detail is rarely important.
 
     In fact if your form is going to be used to directly add or edit a Django
     model, a :doc:`ModelForm </topics/forms/modelforms>` can save you a great
-    deal of time, effort, and code, because it will build a form, along with the
-    appropriate fields and their attributes, from a ``Model`` class.
+    deal of time, effort, and code, because it will build a form, along with
+    the appropriate fields and their attributes, from a ``Model`` class.
 
 Bound and unbound form instances
 --------------------------------

docs/topics/forms/media.txt

@@ -117,7 +117,8 @@ requirements::
             "print": ["newspaper.css"],
         }
 
-If this last CSS definition were to be rendered, it would become the following HTML:
+If this last CSS definition were to be rendered, it would become the following
+HTML:
 
 .. code-block:: html+django
 

docs/topics/forms/modelforms.txt

@@ -311,7 +311,8 @@ the form level.
 
 You can override the error messages from ``NON_FIELD_ERRORS`` raised by model
 validation by adding the :data:`~django.core.exceptions.NON_FIELD_ERRORS` key
-to the ``error_messages`` dictionary of the ``ModelForm``’s inner ``Meta`` class::
+to the ``error_messages`` dictionary of the ``ModelForm``’s inner ``Meta``
+class::
 
     from django.core.exceptions import NON_FIELD_ERRORS
     from django.forms import ModelForm
@@ -440,9 +441,10 @@ fields, especially when new fields are added to a model. Depending on how the
 form is rendered, the problem may not even be visible on the web page.
 
 The alternative approach would be to include all fields automatically, or
-remove only some. This fundamental approach is known to be much less secure
-and has led to serious exploits on major websites (e.g. `GitHub
-<https://github.blog/2012-03-04-public-key-security-vulnerability-and-mitigation/>`_).
+remove only some. This fundamental approach is known to be much less secure and
+has led to serious exploits on major websites (e.g. `GitHub
+<https://github.blog/2012-03-04-public-key-security-vulnerability-and-mitigation/>`__
+).
 
 There are, however, two shortcuts available for cases where you can guarantee
 these security concerns do not apply to you:
@@ -472,13 +474,13 @@ these security concerns do not apply to you:
    ``birth_date``, this will result in the fields ``name`` and ``birth_date``
    being present on the form.
 
-If either of these are used, the order the fields appear in the form will be the
-order the fields are defined in the model, with ``ManyToManyField`` instances
-appearing last.
+If either of these are used, the order the fields appear in the form will be
+the order the fields are defined in the model, with ``ManyToManyField``
+instances appearing last.
 
-In addition, Django applies the following rule: if you set ``editable=False`` on
-the model field, *any* form created from the model via ``ModelForm`` will not
-include that field.
+In addition, Django applies the following rule: if you set ``editable=False``
+on the model field, *any* form created from the model via ``ModelForm`` will
+not include that field.
 
 .. note::
 
@@ -546,11 +548,12 @@ The ``widgets`` dictionary accepts either widget instances (e.g.,
 dictionary is ignored for a model field with a non-empty ``choices`` attribute.
 In this case, you must override the form field to use a different widget.
 
-Similarly, you can specify the ``labels``, ``help_texts`` and ``error_messages``
-attributes of the inner ``Meta`` class if you want to further customize a field.
+Similarly, you can specify the ``labels``, ``help_texts`` and
+``error_messages`` attributes of the inner ``Meta`` class if you want to
+further customize a field.
 
-For example if you wanted to customize the wording of all user facing strings for
-the ``name`` field::
+For example if you wanted to customize the wording of all user facing strings
+for the ``name`` field::
 
     from django.utils.translation import gettext_lazy as _
 
@@ -633,14 +636,14 @@ the field declaratively and setting its ``validators`` parameter::
     ``ModelForm`` is a regular ``Form`` which can automatically generate
     certain fields. The fields that are automatically generated depend on
     the content of the ``Meta`` class and on which fields have already been
-    defined declaratively. Basically, ``ModelForm`` will **only** generate fields
-    that are **missing** from the form, or in other words, fields that weren't
-    defined declaratively.
+    defined declaratively. Basically, ``ModelForm`` will **only** generate
+    fields that are **missing** from the form, or in other words, fields that
+    weren't defined declaratively.
 
     Fields defined declaratively are left as-is, therefore any customizations
-    made to ``Meta`` attributes such as ``widgets``, ``labels``, ``help_texts``,
-    or ``error_messages`` are ignored; these only apply to fields that are
-    generated automatically.
+    made to ``Meta`` attributes such as ``widgets``, ``labels``,
+    ``help_texts``, or ``error_messages`` are ignored; these only apply to
+    fields that are generated automatically.
 
     Similarly, fields defined declaratively do not draw their attributes like
     ``max_length`` or ``required`` from the corresponding model. If you want to
@@ -677,8 +680,8 @@ the field declaratively and setting its ``validators`` parameter::
     contents of the corresponding model field. When they are not compatible,
     you will get a ``ValueError`` as no implicit conversion takes place.
 
-    See the :doc:`form field documentation </ref/forms/fields>` for more information
-    on fields and their arguments.
+    See the :doc:`form field documentation </ref/forms/fields>` for more
+    information on fields and their arguments.
 
 Enabling localization of fields
 -------------------------------
@@ -739,12 +742,12 @@ There are a couple of things to note, however.
   because these classes rely on different metaclasses and a class can only have
   one metaclass.
 
-* It's possible to declaratively remove a ``Field`` inherited from a parent class by
-  setting the name to be ``None`` on the subclass.
+* It's possible to declaratively remove a ``Field`` inherited from a parent
+  class by setting the name to be ``None`` on the subclass.
 
   You can only use this technique to opt out from a field defined declaratively
-  by a parent class; it won't prevent the ``ModelForm`` metaclass from generating
-  a default field. To opt-out from default fields, see
+  by a parent class; it won't prevent the ``ModelForm`` metaclass from
+  generating a default field. To opt-out from default fields, see
   :ref:`modelforms-selecting-fields`.
 
 Providing initial values
@@ -1279,7 +1282,8 @@ a particular author, you could do this:
 
 .. seealso::
 
-    :ref:`Manually rendered can_delete and can_order <manually-rendered-can-delete-and-can-order>`.
+    :ref:`Manually rendered can_delete and can_order
+    <manually-rendered-can-delete-and-can-order>`.
 
 Overriding methods on an ``InlineFormSet``
 ------------------------------------------