         a normal ``str`` or ``unicode`` object and, rather than try to catch
         them all, which would be very difficult, Django repairs the damage after
         the filter has completed.
  
         For example, suppose you have a filter that adds the string ``xx`` to the
         end of any input. Since this introduces no dangerous HTML characters to
         the result (aside from any that were already present), you should mark
         your filter with ``is_safe``::
  
             @register.filter
             def add_xx(value):
                 return '%sxx' % value
             add_xx.is_safe = True
 
</s> remove        your filter function and set it to ``True``, like so::
 </s> add        your filter function and set it to ``True``, like so:

       .. code-block:: python </s> remove        Django will escape the output whenever the input is not already marked as
       "safe".
 </s> add        Django will escape the output whenever the input is not already marked
       as "safe". </s> remove convert an object to its string value before being passed to your function::
 </s> add convert an object to its string value before being passed to your function:

.. code-block:: python </s> remove returned the string, suppose you wanted to pass in a ``DateTimeField`` from an
object and have the template tag format that date-time:
 </s> add returned the string, suppose you wanted to pass in a
:class:`~django.db.models.DateTimeField` from an object and have the template
tag format that date-time: </s> remove tag is used inside a ``{% autoescape off %}`` block.
 </s> add tag is used inside a :ttag:`{% autoescape off %}<autoescape>` block.
       For example, suppose you have a filter that adds the string ``xx`` to
       the end of any input. Since this introduces no dangerous HTML characters
       to the result (aside from any that were already present), you should
       mark your filter with ``is_safe``:

       .. code-block:: python
         a normal ``str`` or ``unicode`` object and, rather than try to catch
         them all, which would be very difficult, Django repairs the damage after
         the filter has completed.
  
       For example, suppose you have a filter that adds the string ``xx`` to
       the end of any input. Since this introduces no dangerous HTML characters
       to the result (aside from any that were already present), you should
       mark your filter with ``is_safe``:

       .. code-block:: python
       For example, suppose you have a filter that adds the string ``xx`` to
       the end of any input. Since this introduces no dangerous HTML characters
       to the result (aside from any that were already present), you should
       mark your filter with ``is_safe``:

       .. code-block:: python
       For example, suppose you have a filter that adds the string ``xx`` to
       the end of any input. Since this introduces no dangerous HTML characters
       to the result (aside from any that were already present), you should
       mark your filter with ``is_safe``:

       .. code-block:: python
       For example, suppose you have a filter that adds the string ``xx`` to
       the end of any input. Since this introduces no dangerous HTML characters
       to the result (aside from any that were already present), you should
       mark your filter with ``is_safe``:

       .. code-block:: python
  
             @register.filter
             def add_xx(value):
                 return '%sxx' % value
             add_xx.is_safe = True
keep keep keep keep replace replace replace replace keep keep keep keep keep
 Brushed up the custom template tag 'howto' guide by moving the assignment_tag doc to a more appropriate place (i.e. under the "Setting a variable in the context" section), adding cross references, fixing a few minor inaccuracies and doing a little PEP8 cleanup.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16909 bcc190cf-cafb-0310-a4f2-bffc1f526a37 
docs/howto/custom-template-tags.txt