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.

1 files changed, 31 insertions, 27 deletions

diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index a5deeb324a..611dc83439 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/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``
 ------------------------------------------