Jinja: El filtro de ajuste de palabras ignora las nuevas líneas existentes

Creado en 5 feb. 2013 · 9Comentarios · Fuente: pallets/jinja

Hola,

Me di cuenta de que al usar este filtro para (por ejemplo) asegurar que un mensaje de correo electrónico siempre esté envuelto en 72 caracteres (cuando sea posible) para garantizar una buena visualización del mismo con la mayor frecuencia posible, notamos que el ajuste de palabras no usaría nuevas líneas existentes en el mensaje como pista, pero en su lugar insertaría nuevas líneas estrictamente cada 72 caracteres.

Esta es nuestra solución

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

No es agradable y completo, pero funciona para nosotros.

Me gustaría que esto (o algo similar) se incluyera en jinja2 propiamente dicho, ya que hace que el filtro wordrwap sea mucho más útil.

¿Qué piensas?

Fuente

dwt

Todos 9 comentarios

No creo que esto sea un error. Wordwrap parece asumir que su texto aún no está ajustado.

untitaker en 5 feb. 2013

👎2

No creo que esto sea un error. Wordwrap parece asumir que su texto aún no está ajustado.

Bueno obviamente. Pero hace que sea realmente difícil de usar en un entorno en el que necesita el ajuste, pero el texto que desea ajustar ya contiene alguna forma de formato (para separar párrafos, por ejemplo).

dwt en 6 feb. 2013

¿Alguna noticia sobre este? Tenemos correos electrónicos de texto sin formato en los que debemos asegurarnos de que los párrafos estén ajustados al final, pero queremos que las líneas dentro del párrafo se ajusten automáticamente. Este parece ser un caso de uso común. De hecho, este cuadro de comentarios en el que estoy escribiendo este mensaje hace lo mismo. Estas líneas se envuelven automáticamente, pero cuando presiono doble enter

comienza un nuevo párrafo.

rbu en 10 feb. 2014

¿No podrías usar el módulo de correo electrónico stdlib para esto?

untitaker en 10 feb. 2014

¿En qué momento insertarías esto?
Estamos usando Jinja2 para generar y localizar correos y después de compilar la plantilla, entregamos la cadena resultante a pyramid_mailer / repoze_sendmail.

Una plantilla de correo electrónico de texto sin formato se parece a esto:

{%- 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 en 10 feb. 2014

También encontré este problema y una búsqueda en Google me llevó aquí. Usar el parche de @dwt funciona para mí. También voto para que este cambio se incorpore al código base.

fossilet en 4 abr. 2014

👍1

Lo mismo aquí, ¡sería genial incorporar la corrección en el maestro!

Tenga en cuenta que wrapstring desapareció en el parche

p2 en 23 sept. 2014

👍1

Envié una solicitud de extracción que soluciona este comportamiento algo inesperado de textwrap.wrap() cuando se trata de varios párrafos.

wrapstring y las líneas vacías se conservan.

Estamos usando esta funcionalidad para generar cuerpos de correo electrónico como parte de otra aplicación y queremos ajustar la entrada en 80 columnas.

fheinle en 7 sept. 2017

También me encuentro con este problema en mi plantilla nbconvert. Sería muy bueno tener el # 766 fusionado, ya que si tengo que escribir mi propio filtro, creo que tendré que escribir un exportador personalizado para nbconvert, lo que estoy tratando de evitar para facilitar el uso.