Jinja: filtro wordwrap ignora novas linhas existentes

Criado em 5 fev. 2013 · 9Comentários · Fonte: pallets/jinja

Olá,

Percebi que ao usar este filtro para (por exemplo) garantir que uma mensagem de e-mail seja sempre quebrada em 72 caracteres (quando possível) para garantir uma boa exibição dela com a maior freqüência possível, percebemos que o wordwrap não usaria novas linhas existentes em a mensagem como pista, mas, em vez disso, inserirá novas linhas estritamente a cada 72 caracteres.

Esta é a nossa solução alternativa

## 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)

Não é bom e completo, mas funciona para nós.

Eu gostaria que isso (ou algo semelhante) fosse incluído no jinja2 apropriado, pois torna o filtro wordrwap muito mais útil.

O que você acha?

Fonte

dwt

Todos 9 comentários

Não acho que seja um bug. A quebra de linha parece apenas assumir que o seu texto ainda não foi quebrado.

untitaker em 5 fev. 2013

👎2

Não acho que seja um bug. A quebra de linha parece apenas assumir que o seu texto ainda não foi quebrado.

Bem, obviamente. Mas torna realmente difícil de usar em um ambiente onde você precisa da quebra, mas o texto que você quer quebrar já contém Alguma forma de formatação (para separar Parágrafos, por exemplo).

dwt em 6 fev. 2013

Algumas notícias sobre este? Temos e-mails de texto simples em que precisamos garantir que os parágrafos sejam quebrados no final, mas queremos que as linhas dentro do parágrafo sejam quebradas automaticamente. Este parece ser um caso de uso comum. Na verdade, esta caixa de comentário na qual estou digitando esta mensagem faz o mesmo. Essas linhas são quebradas automaticamente, mas quando eu pressiono duas vezes a tecla Enter

um novo parágrafo começa.

rbu em 10 fev. 2014

Você não poderia usar o módulo de e-mail stdlib para isso?

untitaker em 10 fev. 2014

Em que ponto você inseriria isso?
Estamos usando o Jinja2 para gerar e localizar e-mails e, após compilar o modelo, passe a string resultante para pyramid_mailer / repoze_sendmail.

Um modelo de e-mail de texto simples se parece com isto:

{%- 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 %}

...

rbu em 10 fev. 2014

Eu também encontrei esse problema e uma pesquisa no Google me trouxe até aqui. Usar o patch de @dwt funciona para mim. Eu também voto para que esta mudança seja incorporada na base de código.

fossilet em 4 abr. 2014

👍1

O mesmo aqui, seria ótimo incorporar a correção no master!

Observe que wrapstring desapareceu do patch

p2 em 23 set. 2014

👍1

Enviei uma solicitação de pull que contorna esse comportamento um tanto inesperado de textwrap.wrap() ao lidar com vários parágrafos.

wrapstring e as linhas vazias são preservadas.

Estamos usando essa funcionalidade para gerar corpos de email como parte de outro aplicativo e queremos agrupar a entrada em 80 colunas.

fheinle em 7 set. 2017

Estou encontrando esse problema também em meu modelo nbconvert. Seria muito bom ter o # 766 mesclado, pois se eu tiver que escrever meu próprio filtro, acredito que terei que escrever um exportador personalizado para nbconvert, o que, para facilitar o uso, estou tentando evitar.