Jinja: يتجاهل عامل تصفية التفاف الكلمات الأسطر الجديدة الموجودة

تم إنشاؤها على ٥ فبراير ٢٠١٣ · 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 أكثر فائدة.

ماذا تعتقد؟

مصدر

dwt

ال 9 كومينتر

لا أعتقد أن هذا خطأ. يبدو أن Wordwrap يفترض فقط أن النص لم يتم تغليفه بعد.

untitaker في ٥ فبراير ٢٠١٣

👎2

لا أعتقد أن هذا خطأ. يبدو أن Wordwrap يفترض فقط أن النص لم يتم تغليفه بعد.

من الواضح تماما. ولكنه يجعل من الصعب حقًا استخدامه في بيئة تحتاج فيها إلى الالتفاف ولكن النص الذي تريد التفافه يحتوي بالفعل على بعض أشكال التنسيق (لفصل الفقرات على سبيل المثال).

dwt في ٦ فبراير ٢٠١٣

أي أخبار عن هذه؟ لدينا رسائل بريد إلكتروني ذات نص عادي حيث نحتاج إلى التأكد من التفاف الفقرات في النهاية ، لكننا نريد التفاف الأسطر داخل الفقرة تلقائيًا. يبدو أن هذه حالة استخدام شائعة. في الواقع ، مربع التعليق هذا الذي أكتب فيه هذه الرسالة يفعل نفس الشيء. يتم تغليف هذه الأسطر تلقائيًا ، ولكن عندما أضغط على زر الإدخال المزدوج

تبدأ فقرة جديدة.

rbu في ١٠ فبراير ٢٠١٤

ألا يمكنك استخدام وحدة البريد الإلكتروني stdlib لهذا؟

untitaker في ١٠ فبراير ٢٠١٤

في أي نقطة تقوم بإدخال هذا؟
نحن نستخدم 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 %}

...

rbu في ١٠ فبراير ٢٠١٤

واجهت أيضًا هذه المشكلة وقادني بحث Google إلى هنا. استخدام التصحيح من dwt يعمل بالنسبة لي. أنا أيضًا أصوت لهذا التغيير ليتم دمجه في قاعدة الكود.

fossilet في ٤ أبريل ٢٠١٤

👍1

بالمثل هنا ، سيكون من الرائع دمج الإصلاح في البرنامج الرئيسي!

لاحظ أن wrapstring اختفى في التصحيح

p2 في ٢٣ سبتمبر ٢٠١٤

👍1

لقد قدمت طلبات سحب تعمل على حل هذا السلوك غير المتوقع إلى حد ما وهو textwrap.wrap() عند التعامل مع فقرات متعددة.

wrapstring ويتم الاحتفاظ بالأسطر الفارغة.

نحن نستخدم هذه الوظيفة لإنشاء نصوص بريد إلكتروني كجزء من تطبيق آخر ونريد التفاف الإدخال في 80 عمودًا.

fheinle في ٧ سبتمبر ٢٠١٧

أواجه هذه المشكلة أيضًا في نموذج nbconvert الخاص بي. سيكون من الرائع جدًا دمج # 766 لأنه إذا اضطررت إلى كتابة عامل التصفية الخاص بي ، أعتقد أنه سيتعين علي كتابة مُصدر مخصص لـ nbconvert ، والذي أحاول تجنبه لسهولة الاستخدام.