Minor rewrite of linebreaks and linebreaksbr

[Johan Bergström <bugs@…>]

This relatively small patch modifieslinebreaks and linebreaksbr. They now share the same backend (django.utils.html.linebreaks) which makes linebreaksbr accept additional types of newlines (\r\n etc). This patch also adds support for html (as addition to xhtml) output which are passed in as an argument to the filter:

    <h1>linebreaks/linebreaksbr both accepts "html" or 0 (False) as argument</h1>
    {{ blog.entry|linebreaks:"html" }}

Both filters and util defaults to xhtml output (the current behaviour).

[Johan Bergström <bugs@…>]

Includes patch, docs and tests.

[Lfe]

Last patch somehow didn't apply cleanly. Here's the new version (with a proper mime-type)

[Johan Bergström <bugs@…>]

Safari somehow got my IRC nickname as name when posting the updated patch, sorry for any confusion this may have caused...

[Johan Bergström <bugs@…>]

...and here's the slightly updated version. Should save a cpu cycle and fix a nasty bug (is vs ==).

[Johan Bergström <bugs@…>]

Fixed a typo..

[Chris Beaven]

How about changing

xhtml = True 
if arg == "html": 
    xhtml = False 

to

xhtml = (arg != 'html')

[Johan Bergström <bugs@…>]

SmileyChris: My major itch was HTML (as an option to XHTML) support - which should be outlined in my patch. If the committer feels that my code could be rewritter further - you/he/she has my blessing :-)

[Johan Bergström <bugs@…>]

Fourth revision of the patch

[Johan Bergström <bugs@…>]

Ok. Here's another stab at this. I've implemented the improvement SmileyChris suggested. This should also apply cleanly after the unicode merge. I modified the test case for linebreaks so it accepts arguments and added extra test cases for linebreaksbr. One thing this patch also does is change the newline output from <br /> to <br/>, since using truncatewords will strip the line break containing a space (bug of feature?). I guess most people write line breaks with spaces, but this patch is slimmer than modifying truncatewords.

[Malcolm Tredinnick]

I haven't read the patch yet, so I have no comment on the specifics, however one thing in your comment raises alarms.

The space before the slash in <br /> is required for HTML parsing. The trailing slash is actually invalid in HTML (as opposed to XHTML) and so it is exploiting the required error recovery behaviour in order to work. You can't just remove it or there will be subtle errors in some renderers when used in SGML-based HTML output.

[Chris Beaven]

You shouldn't be using truncatewords after that filter - it's not HTML aware (that's why I wrote the truncatewords_html filter) so it's not something you need to worry about.

[Johan Bergström <bugs@…>]

Thank you both for feedback. Here's the same patch with the <br/> behaviour reverted.

[Jacob]

While there's nothing technically wrong with this patch, I just don't see a reason to include it since it's just code churn.