Jinja: фильтр переноса слов игнорирует существующие символы новой строки

Созданный на 5 февр. 2013  ·  9Комментарии  ·  Источник: pallets/jinja

Всем привет,

Я заметил, что при использовании этого фильтра (например) для обеспечения того, чтобы сообщение электронной почты всегда было перенесено на 72 символа (где это возможно), чтобы обеспечить его хорошее отображение как можно чаще, мы заметили, что перенос слов не будет использовать существующие символы новой строки в сообщение как подсказка, но вместо этого вставляет новые строки строго каждые 72 символа.

Это наш обходной путь

## Workaround bug in do_wordwrap where it disregards existing linebreaks 
## when wrapping text

from jinja2.filters import environmentfilter
import re
<strong i="8">@environmentfilter</strong>
def do_wordwrap(environment, s, width=79, break_long_words=True):
    """
    Return a copy of the string passed to the filter wrapped after
    ``79`` characters.  You can override this default using the first
    parameter.  If you set the second parameter to `false` Jinja will not
    split words apart if they are longer than `width`.
    """
    import textwrap
    accumulator = []
    # Workaround: pre-split the string
    for component in re.split(r"\r?\n", s):
        # textwrap will eat empty strings for breakfirst. Therefore we route them around it.
        if len(component) is 0:
            accumulator.append(component)
            continue
        accumulator.extend(
            textwrap.wrap(component, width=width, expand_tabs=False,
                replace_whitespace=False,
                break_long_words=break_long_words)
        )
    return environment.newline_sequence.join(accumulator)

Не красиво и полно, но у нас работает.

Я бы хотел, чтобы это (или что-то подобное) было включено непосредственно в jinja2, поскольку это делает фильтр wordrwap гораздо более полезным.

Что вы думаете?

Все 9 Комментарий

Не думаю, что это ошибка. Wordwrap, кажется, предполагает, что ваш текст еще не перенесен.

Не думаю, что это ошибка. Wordwrap, кажется, предполагает, что ваш текст еще не перенесен.

Что ж, очевидно. Но это действительно затрудняет использование в среде, где вам нужна упаковка, но текст, который вы хотите обернуть, уже содержит некоторую форму форматирования (например, для разделения абзацев).

Есть новости по этому поводу? У нас есть простые текстовые электронные письма, в которых нам нужно обеспечить перенос абзацев в конце, но мы хотим, чтобы строки внутри абзаца были автоматически перенесены. Кажется, это обычный вариант использования. Фактически, это поле для комментариев, в котором я печатаю это сообщение, делает то же самое. Эти строки переносятся автоматически, но когда я нажимаю двойной ввод

начинается новый абзац.

Не могли бы вы использовать для этого модуль электронной почты stdlib?

В какой момент вы бы это вставили?
Мы используем Jinja2 для генерации и локализации писем и после компиляции шаблона передаем полученную строку в pyramid_mailer / repoze_sendmail.

Шаблон электронного письма с открытым текстом выглядит примерно так:

{%- filter wordwrap(width=72, break_long_words=False) -%}
{% block greeting -%}
{% trans full_name = _(user.full_name) %}Hello {{ full_name }},{% endtrans %}
{% endblock -%}

{% block message_intro %}
{% endblock -%}

{% trans -%}
This may be a very long text in another language, depending on what a translator put into the gettext localization. It may even have its own paragraphs.
{%- endtrans %}

...

Я тоже столкнулся с этой проблемой, и поиск в Google привел меня сюда. У меня работает патч от

То же самое, было бы здорово включить исправление в мастер!

Обратите внимание, что wrapstring исчез в патче

Я отправил запросы на вытягивание, которые позволяют обойти это несколько неожиданное поведение textwrap.wrap() при работе с несколькими абзацами.

wrapstring и пустые строки сохраняются.

Мы используем эту функцию для создания тел электронной почты как часть другого приложения и хотим заключить ввод в 80 столбцов.

Я также сталкиваюсь с этой проблемой в моем шаблоне nbconvert. Было бы очень приятно объединить # 766, поскольку, если мне придется написать свой собственный фильтр, я считаю, что мне придется написать собственный экспортер для nbconvert, чего для простоты использования я стараюсь избегать.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги